rfc3161.txt

PKIX的RFC英文文档

Network Working Group                                           C. Adams
Request for Comments: 3161                                       Entrust
Category: Standards Track                                        P. Cain
                                                                     BBN
                                                               D. Pinkas
                                                                Integris
                                                           R. Zuccherato
                                                                 Entrust
                                                             August 2001


                Internet X.509 Public Key Infrastructure
                       Time-Stamp Protocol (TSP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes the format of a request sent to a Time
   Stamping Authority (TSA) and of the response that is returned.  It
   also establishes several security-relevant requirements for TSA
   operation, with regards to processing requests to generate responses.

1.  Introduction

   A time-stamping service supports assertions of proof that a datum
   existed before a particular time.  A TSA may be operated as a Trusted
   Third Party (TTP) service, though other operational models may be
   appropriate, e.g., an organization might require a TSA for internal
   time-stamping purposes.

   Non-repudiation services [ISONR] require the ability to establish the
   existence of data before specified times.  This protocol may be used
   as a building block to support such services.  An example of how to
   prove that a digital signature was generated during the validity
   period of a public key certificate is given in an annex.





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


   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
   uppercase, as shown) are to be interpreted as described in [RFC2119].

   In order to associate a datum with a particular point in time, a Time
   Stamp Authority (TSA) may need to be used.  This Trusted Third Party
   provides a "proof-of-existence" for this particular datum at an
   instant in time.

   The TSA's role is to time-stamp a datum to establish evidence
   indicating that a datum existed before a particular time.  This can
   then be used, for example, to verify that a digital signature was
   applied to a message before the corresponding certificate was revoked
   thus allowing a revoked public key certificate to be used for
   verifying signatures created prior to the time of revocation.  This
   is an important public key infrastructure operation.  The TSA can
   also be used to indicate the time of submission when a deadline is
   critical, or to indicate the time of transaction for entries in a
   log.  An exhaustive list of possible uses of a TSA is beyond the
   scope of this document.

   This standard does not establish overall security requirements for
   TSA operation, just like other PKIX standards do not establish such
   requirements for CA operation.  Rather, it is anticipated that a TSA
   will make known to prospective clients the policies it implements to
   ensure accurate time-stamp generation, and clients will make use of
   the services of a TSA only if they are satisfied that these policies
   meet their needs.

2. The TSA

   The TSA is a TTP that creates time-stamp tokens in order to indicate
   that a datum existed at a particular point in time.

   For the remainder of this document a "valid request" shall mean one
   that can be decoded correctly, is of the form specified in Section
   2.4, and is from a supported TSA subscriber.

2.1. Requirements of the TSA

   The TSA is REQUIRED:

   1.    to use a trustworthy source of time.

   2.    to include a trustworthy time value for each time-stamp token.

   3.    to include a unique integer for each newly generated time-stamp
         token.



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


   4.    to produce a time-stamp token upon receiving a valid request
         from the requester, when it is possible.

   5.    to include within each time-stamp token an identifier to
         uniquely indicate the security policy under which the token was
         created.

   6.    to only time-stamp a hash representation of the datum, i.e., a
         data imprint associated with a one-way collision resistant
         hash-function uniquely identified by an OID.

   7.    to examine the OID of the one-way collision resistant hash-
         function and to verify that the hash value length is consistent
         with the hash algorithm.

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

   9.    not to include any identification of the requesting entity in
         the time-stamp tokens.

   10.   to sign each time-stamp token using a key generated exclusively
         for this purpose and have this property of the key indicated on
         the corresponding certificate.

   11.   to include additional information in the time-stamp token, if
         asked by the requester using the extensions field, only for the
         extensions that are supported by the TSA.  If this is not
         possible, the TSA SHALL respond with an error message.

2.2. TSA Transactions

   As the first message of this mechanism, the requesting entity
   requests a time-stamp token by sending a request (which is or
   includes a TimeStampReq, as defined below) to the Time Stamping
   Authority.  As the second message, the Time Stamping Authority
   responds by sending a response (which is or includes a TimeStampResp,
   as defined below) to the requesting entity.

   Upon receiving the response (which is or includes a TimeStampResp
   that normally contains a TimeStampToken (TST), as defined below), the
   requesting entity SHALL verify the status error returned in the
   response and if no error is present it SHALL verify the various
   fields contained in the TimeStampToken and the validity of the
   digital signature of the TimeStampToken.  In particular, it SHALL
   verify that what was time-stamped corresponds to what was requested
   to be time-stamped.  The requester SHALL verify that the
   TimeStampToken contains the correct certificate identifier of the



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


   TSA, the correct data imprint and the correct hash algorithm OID.  It
   SHALL then verify the timeliness of the response by verifying either
   the time included in the response against a local trusted time
   reference, if one is available, or the value of the nonce (large
   random number with a high probability that it is generated by the
   client only once) included in the response against the value included
   in the request.  For more details about replay attack detection, see
   the security considerations section (item 6).  If any of the
   verifications above fails, the TimeStampToken SHALL be rejected.

   Then, since the TSA's certificate may have been revoked, the status
   of the certificate SHOULD be checked (e.g., by checking the
   appropriate CRL) to verify that the certificate is still valid.

   Then, the client application SHOULD check the policy field to
   determine whether or not the policy under which the token was issued
   is acceptable for the application.

2.3. Identification of the TSA

   The TSA MUST sign each time-stamp message with a key reserved
   specifically for that purpose.  A TSA MAY have distinct private keys,
   e.g., to accommodate different policies, different algorithms,
   different private key sizes or to increase the performance.  The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.

   The following object identifier identifies the KeyPurposeID having
   value id-kp-timeStamping.

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

2.4. Request and Response Formats

2.4.1. Request Format

   A time-stamping request is as follows:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be



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


     --time-stamped
   reqPolicy             TSAPolicyId              OPTIONAL,
   nonce                 INTEGER                  OPTIONAL,
   certReq               BOOLEAN                  DEFAULT FALSE,
   extensions            [0] IMPLICIT Extensions  OPTIONAL  }

   The version field (currently v1) describes the version of the Time-
   Stamp request.

   The messageImprint field SHOULD contain the hash of the datum to be
   time-stamped.  The hash is represented as an OCTET STRING.  Its
   length MUST match the length of the hash value for that algorithm
   (e.g., 20 bytes for SHA-1 or 16 bytes for MD5).

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

   The hash algorithm indicated in the hashAlgorithm field SHOULD be a
   known hash algorithm (one-way and collision resistant).  That means
   that it SHOULD be one-way and collision resistant.  The Time Stamp
   Authority SHOULD check whether or not the given hash algorithm is
   known to be "sufficient" (based on the current state of knowledge in
   cryptanalysis and the current state of the art in computational
   resources, for example).  If the TSA does not recognize the hash
   algorithm or knows that the hash algorithm is weak (a decision left
   to the discretion of each individual TSA), then the TSA SHOULD refuse
   to provide the time-stamp token by returning a pkiStatusInfo of
   'bad_alg'.

   The reqPolicy field, if included, indicates the TSA policy under
   which the TimeStampToken SHOULD be provided.  TSAPolicyId is defined
   as follows:

      TSAPolicyId ::= OBJECT IDENTIFIER

   The nonce, if included, allows the client to verify the timeliness of
   the response when no local clock is available.  The nonce is a large
   random number with a high probability that the client generates it
   only once (e.g., a 64 bit integer).  In such a case the same nonce
   value MUST be included in the response, otherwise the response shall
   be rejected.

   If the certReq field is present and set to true, the TSA's public key
   certificate that is referenced by the ESSCertID identifier inside a
   SigningCertificate attribute in the response MUST be provided by the
   TSA in the certificates field from the SignedData structure in that
   response.  That field may also contain other certificates.



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


   If the certReq field is missing or if the certReq field is present
   and set to false then the certificates field from the SignedData
   structure MUST not be present in the response.

   The extensions field is a generic way to add additional information
   to the request in the future.  Extensions is defined in [RFC 2459].
   If an extension, whether it is marked critical or not critical, is
   used by a requester but is not recognized by a time-stamping server,
   the server SHALL not issue a token and SHALL return a failure
   (unacceptedExtension).

   The time-stamp request does not identify the requester, as this
   information is not validated by the TSA (See Section 2.1).  In
   situations where the TSA requires the identity of the requesting
   entity, alternate identification /authentication means have to be
   used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC2246]).

2.4.2. Response Format

   A time-stamping response is as follows:

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

   The status is based on the definition of status in section 3.2.3
   of [RFC2510] as follows:

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

   When the status contains the value zero or one, a TimeStampToken MUST
   be present.  When status contains a value other than zero or one, a
   TimeStampToken MUST NOT be present.  One of the following values MUST
   be contained in status:

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



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


       -- this message contains a warning that a revocation is
       -- imminent
      revocationNotification (5)
       -- notification that a revocation has occurred  }

   Compliant servers SHOULD NOT produce any other values. Compliant
   clients MUST generate an error if values it does not understand are
   present.

   When the TimeStampToken is not present, the 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),