rfc3161.txt

PKIX的RFC英文文档

   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:



Adams, et al.               Standards Track                    [Page 20]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


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

      1)    The signature is presented to the Time Stamping Authority
            (TSA).  The TSA 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 TSA 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 TSA 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
            the TSA.

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

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




Adams, et al.               Standards Track                    [Page 21]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


     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  }

TSAPolicyId ::= OBJECT IDENTIFIER


-- 2.4.2

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



Adams, et al.               Standards Track                    [Page 22]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


-- 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 TSA's time source is not available
    unacceptedPolicy    (15),
      -- the requested TSA policy is not supported by the TSA.
    unacceptedExtension (16),
      -- the requested extension is not supported by the TSA.
    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  }

TimeStampToken ::= ContentInfo



Adams, et al.               Standards Track                    [Page 23]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


     -- 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

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 TSA's certificate MAY contain a Subject Information Access (SIA)
   extension (son of RFC2459) in order to convey the method of
   contacting the TSA.  The accessMethod field in this extension MUST
   contain the OID id-ad-timestamping:

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



Adams, et al.               Standards Track                    [Page 24]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


   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 TSA and may contain other transport
   dependent information (e.g., a URL).











































Adams, et al.               Standards Track                    [Page 25]

RFC 3161               Time-Stamp Protocol (TSP)             August 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Adams, et al.               Standards Track                    [Page 26]