draft-ietf-pkix-rfc3161bis-00.txt

PKIX的RFC英文文档

PKIX Working Group                                           C. Adams
draft-ietf-pkix-rfc3161bis-00.txt                                Entrust
Target category: Draft Standard                                  P. Cain
Expires in 6 months                                                  BBN
                                                               D. Pinkas
                                                                    Bull
                                                           R. Zuccherato
                                                                 Entrust
                                                              April 2002

                Internet X.509 Public Key Infrastructure
                       Time-Stamp Protocol (TSP)
                   <draft-ietf-pkix-rfc3161bis-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   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-bis           Time-Stamp Protocol (TSP)              April 2002


   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, in the form of a time-stamp token.

   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.  A time-stamp 
   token 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 time-stamp 
   tokens 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.

   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. The TSU

   The TSU (Time-Stamp Unit) is the set of hardware and software which 
   is managed as a unit by one TSA and has a single signing key active 
   at a time. It creates time-stamp tokens in order to indicate that a 
   datum existed at a particular point in time.

2.1. Requirements for the TSU

   The TSU 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.

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

Adams, et al.               Standards Track                     [Page 2

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

   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 TSU.  If this is not
         possible, the TSU SHALL respond with an error message.

2.2. TSU 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
   Unit.  As the second message, the Time Stamping Unit 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
   TSU, 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.

Adams, et al.               Standards Track                     [Page 3

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


   Then, since the TSU'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 TSU

   The TSU MUST sign each time-stamp message with a key reserved
   specifically for that purpose. A TSA MAY have distinct TSUs, each 
   one holding a different private key, e.g., to accommodate different 
   policies, different algorithms, different private key sizes or to 
   increase the performance. The corresponding TSU certificate MUST 
   be able to identify the TSA and 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
     --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).


Adams, et al.               Standards Track                     [Page 4

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


   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 TSU does not recognize the hash
   algorithm or knows that the hash algorithm is weak (a decision left
   to the discretion of each individual TSU), then the TSU 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 SHALL 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 TSU's public key
   certificate that is referenced by the ESSCertID identifier inside a
   SigningCertificate attribute in the response MUST be provided by the
   TSU in the certificates field from the SignedData structure in that
   response.  That field may also contain other certificates.

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

   A server that does not recognize a non-critical extension SHALL 
   ignore the extension and SHALL NOT return an error for this. 
   A server that recognizes an extension SHALL process the extension 
   regardless of the value of the criticality flag. A server MUST 
   reject the request if it encounters a critical extension it does 
   not recognize and in that case SHALL return a failure
   (unacceptedExtension).




Adams, et al.               Standards Track                     [Page 5

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


   The time-stamp request does not identify the requester, as this
   information is not validated by the TSU (See Section 2.1).  In
   situations where the TSU 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),
       -- 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.





Adams, et al.               Standards Track                     [Page 6

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