draft-ietf-pkix-rfc3161bis-00.txt

PKIX的RFC英文文档

   One of the major uses of time-stamping is to time-stamp a digital
   signature to prove that the digital signature was created before a
   given time.  Should the corresponding public key certificate be
   revoked this allows a verifier to know whether the signature was
   created before or after the revocation date.

   A sensible place to store a time-stamp is in a [CMS] structure as an
   unsigned attribute.

   This appendix defines a Signature Time-stamp attribute that may be
   used to time-stamp a digital signature.

   The following object identifier identifies the Signature Time-stamp
   attribute:

   id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

   The Signature time-stamp attribute value has ASN.1 type
   SignatureTimeStampToken:

   SignatureTimeStampToken ::= TimeStampToken

   The value of messageImprint field within TimeStampToken shall be a
   hash of the value of signature field within SignerInfo for the
   signedData being time-stamped.

APPENDIX B - Placing a Signature At a Particular Point in Time

   We present an example of a possible use of this general time-stamping
   service.  It places a signature at a particular point in time, from
   which the appropriate certificate status information (e.g., CRLs)
   MUST be checked.  This application is intended to be used in
   conjunction with evidence generated using a digital signature
   mechanism.

   Signatures can only be verified according to a non-repudiation
   policy. This policy MAY be implicit or explicit (i.e., indicated in
   the evidence provided by the signer).  The non-repudiation policy can
   specify, among other things, the time period allowed by a signer to
   declare the compromise of a signature key used for the generation of
   digital signatures.  Thus a signature may not be guaranteed to be
   valid until the termination of this time period.

   To verify a digital signature, the following basic technique may be
   used:


   A) Time-stamping information needs to be obtained soon after the
      signature has been produced (e.g., within a few minutes or hours).


Adams, et al.               Standards Track                    [Page 19

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


      1)    The signature is presented to a Time Stamping Unit 
            (TSU).  The TSU then returns a TimeStampToken (TST) upon
            that signature.

      2)    The invoker of the service MUST then verify that the
            TimeStampToken is correct.

   B) The validity of the digital signature may then be verified in the
      following way:

      1)    The time-stamp token itself MUST be verified and it MUST be
            verified that it applies to the signature of the signer.

      2)    The date/time indicated by the TSU in the TimeStampToken
            MUST be retrieved.

      3)    The certificate used by the signer MUST be identified and
            retrieved.

      4)    The date/time indicated by the TSU MUST be within the
            validity period of the signer's certificate.

      5)    The revocation information about that certificate, at the
            date/time of the Time-Stamping operation, MUST be retrieved.

      6)    Should the certificate be revoked, then the date/time of
            revocation shall be later than the date/time indicated by
            in the time-stamp token from the TSU.

   If all these conditions are successful, then the digital signature
   shall be declared as valid.























Adams, et al.               Standards Track                    [Page 20

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


APPENDIX C: ASN.1 Module using 1988 Syntax

PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

     Extensions, AlgorithmIdentifier
     FROM PKIX1Explicit88 {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
     id-mod(0) id-pkix1-explicit-88(1)}

     GeneralName FROM PKIX1Implicit88 {iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

     ContentInfo FROM CryptographicMessageSyntax {iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) cms(1)}

     PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-cmp(9)} ;

                     --  Locally defined OIDs  --

-- eContentType for a time-stamp token

id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

-- 2.4.1

TimeStampReq ::= SEQUENCE  {
   version                  INTEGER  { v1(1) },
   messageImprint           MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy                TSAPolicyId                OPTIONAL,
   nonce                    INTEGER                    OPTIONAL,
   certReq                  BOOLEAN                    DEFAULT FALSE,
   extensions               [0] IMPLICIT Extensions    OPTIONAL  }

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }


Adams, et al.               Standards Track                    [Page 21

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002

TSAPolicyId ::= OBJECT IDENTIFIER

-- 2.4.2

TimeStampResp ::= SEQUENCE  {
     status                  PKIStatusInfo,
     timeStampToken          TimeStampToken     OPTIONAL  }

-- The status is based on the definition of status
-- in section 3.2.3 of [RFC2510]

PKIStatusInfo ::= SEQUENCE {
    status        PKIStatus,
    statusString  PKIFreeText     OPTIONAL,
    failInfo      PKIFailureInfo  OPTIONAL  }

PKIStatus ::= INTEGER {
    granted                (0),
    -- when the PKIStatus contains the value zero a TimeStampToken, as
       requested, is present.
    grantedWithMods        (1),
     -- when the PKIStatus contains the value one a TimeStampToken,
       with modifications, is present.
    rejection              (2),
    waiting                (3),
    revocationWarning      (4),
     -- this message contains a warning that a revocation is
     -- imminent
    revocationNotification (5)
     -- notification that a revocation has occurred   }

    -- When the TimeStampToken is not present
    -- failInfo indicates the reason why the
    -- time-stamp request was rejected and
    -- may be one of the following values.

PKIFailureInfo ::= BIT STRING {
    badAlg               (0),
      -- unrecognized or unsupported Algorithm Identifier
    badRequest           (2),
      -- transaction not permitted or supported
    badDataFormat        (5),
      -- the data submitted has the wrong format
    timeNotAvailable    (14),
      -- the TSU's time source is not available
    unacceptedPolicy    (15),
      -- the requested TSA policy is not supported by the TSU.
    unacceptedExtension (16),
      -- the requested extension is not supported by the TSU.
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }

Adams, et al.               Standards Track                    [Page 22

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002

TimeStampToken ::= ContentInfo

     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo
     -- eContent within SignedData is TSTInfo

TSTInfo ::= SEQUENCE  {
    version                      INTEGER  { v1(1) },
    policy                       TSAPolicyId,
    messageImprint               MessageImprint,
      -- MUST have the same value as the similar field in
      -- TimeStampReq
    serialNumber                 INTEGER,
     -- Time-Stamping users MUST be ready to accommodate integers
     -- up to 160 bits.
    genTime                      GeneralizedTime,
    accuracy                     Accuracy                 OPTIONAL,
    ordering                     BOOLEAN             DEFAULT FALSE,
    nonce                        INTEGER                  OPTIONAL,
      -- MUST be present if the similar field was present
      -- in TimeStampReq.  In that case it MUST have the same value.
    tsa                          [0] GeneralName          OPTIONAL,
    extensions                   [1] IMPLICIT Extensions  OPTIONAL   }

Accuracy ::= SEQUENCE {
                seconds        INTEGER           OPTIONAL,
                millis     [0] INTEGER  (1..999) OPTIONAL,
                micros     [1] INTEGER  (1..999) OPTIONAL  }

END
























Adams, et al.               Standards Track                    [Page 23

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


APPENDIX D: Access descriptors for Time-Stamping.

   [This annex describes an extension based on the SIA extension that
   will be defined in the "son-of-RFC2459".  Since at the time of
   publication of this document, "son-of-RFC2459" is not yet available,
   its description is placed in an informative annex.  The contents of
   this annex will eventually become incorporated into the son-of-
   RFC2459 document, at which time this annex will no longer be needed.
   A future version of this document will likely omit this annex and
   refer to son-of-RFC2459 directly.]

   A TSU's certificate MAY contain a Subject Information Access (SIA)
   extension (son of RFC2459) in order to convey the method of
   contacting the TSU.  The accessMethod field in this extension MUST
   contain the OID id-ad-timestamping:

   The following object identifier identifies the access descriptors for
   time-Stamping.

   id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
                         identified-organization(3) dod(6)
                         internet(1) security(5) mechanisms(5) pkix(7)
                         ad (48) timestamping (3)}

   The value of the accessLocation field defines the transport (e.g.,
   HTTP) used to access the TSU and may contain other transport
   dependent information (e.g., a URL).



























Adams, et al.               Standards Track                    [Page 24

RFC 3161-bis           Time-Stamp Protocol (TSP)              April 2002


APPENDIX E: Summary of changes with RFC 3161.

CHANGE N