rfc3161.txt

PKIX的RFC英文文档


RFC 3161               Time-Stamp Protocol (TSP)             August 2001


3.4. Time-Stamp Protocol via HTTP

   This subsection specifies a means for conveying ASN.1-encoded
   messages for the protocol exchanges described in Section 2 and
   Appendix D via the HyperText Transfer Protocol.

   Two MIME objects are specified as follows.

   Content-Type: application/timestamp-query

      <<the ASN.1 DER-encoded Time-Stamp Request message>>

   Content-Type: application/timestamp-reply

      <<the ASN.1 DER-encoded Time-Stamp Response message>>

   These MIME objects can be sent and received using common HTTP
   processing engines over WWW links and provides a simple browser-
   server transport for Time-Stamp messages.

   Upon receiving a valid request, the server MUST respond with either a
   valid response with content type application/timestamp-response or
   with an HTTP error.

4. Security Considerations

   This entire document concerns security considerations.  When
   designing a TSA service, the following considerations have been
   identified that have an impact upon the validity or "trust" in the
   time-stamp token.

   1. When a TSA shall not be used anymore, but the TSA private key has
      not been compromised, the authority's certificate SHALL be
      revoked.  When the reasonCode extension relative to the revoked
      certificate from the TSA is present in the CRL entry extensions,
      it SHALL be set either to unspecified (0), affiliationChanged (3),
      superseded (4) or cessationOfOperation (5).  In that case, at any
      future time, the tokens signed with the corresponding key will be
      considered as invalid, but tokens generated before the revocation
      time will remain valid.  When the reasonCode extension relative to
      the revoked certificate from the TSA is not present in the CRL
      entry extensions, then all the tokens that have been signed with
      the corresponding key SHALL be considered as invalid.  For that
      reason, it is recommended to use the reasonCode extension.







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


   2. When the TSA private key has been compromised, then the
      corresponding certificate SHALL be revoked.  In that case, the
      reasonCode extension relative to the revoked certificate from the
      TSA may or may not be present in the CRL entry extensions.  When
      it is present then it SHALL be set to keyCompromise (1).  Any
      token signed by the TSA using that private key cannot be trusted
      anymore.  For this reason, it is imperative that the TSA's private
      key be guarded with proper security and controls in order to
      minimize the possibility of compromise.  In case the private key
      does become compromised, an audit trail of all tokens generated by
      the TSA MAY provide a means to discriminate between genuine and
      false backdated tokens.  Two time-stamp tokens from two different
      TSAs is another way to address this issue.

   3. The TSA signing key MUST be of a sufficient length to allow for a
      sufficiently long lifetime.  Even if this is done, the key will
      have a finite lifetime.  Thus, any token signed by the TSA SHOULD
      be time-stamped again (if authentic copies of old CRLs are
      available) or notarized (if they aren't) at a later date to renew
      the trust that exists in the TSA's signature. time-stamp tokens
      could also be kept with an Evidence Recording Authority to
      maintain this trust.

   4. A client application using only a nonce and no local clock SHOULD
      be concerned about the amount of time it is willing to wait for a
      response.  A `man-in-the-middle' attack can introduce delays.
      Thus, any TimeStampResp that takes more than an acceptable period
      of time SHOULD be considered suspect.  Since each transport method
      specified in this document has different delay characteristics,
      the period of time that is considered acceptable will depend upon
      the particular transport method used, as well as other environment
      factors.

   5. If different entities obtain time-stamp tokens on the same data
      object using the same hash algorithm, or a single entity obtains
      multiple time-stamp tokens on the same object, the generated
      time-stamp tokens will include identical message imprints; as a
      result, an observer with access to those time-stamp tokens could
      infer that the time-stamps may refer to the same underlying data.












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


   6. Inadvertent or deliberate replays for requests incorporating the
      same hash algorithm and value may happen.  Inadvertent replays
      occur when more than one copy of the same request message gets
      sent to the TSA because of problems in the intervening network
      elements.  Deliberate replays occur when a middleman is replaying
      legitimate TS responses.  In order to detect these situations,
      several techniques may be used.  Using a nonce always allows to
      detect replays, and hence its use is RECOMMENDED.  Another
      possibility is to use both a local clock and a moving time window
      during which the requester remembers all the hashes sent during
      that time window.  When receiving a response, the requester
      ensures both that the time of the response is within the time
      window and that there is only one occurrence of the hash value in
      that time window.  If the same hash value is present more than
      once within a time window, the requester may either use a nonce,
      or wait until the time window has moved to come back to the case
      where the same hash value appears only once during that time
      window.

5. Intellectual Property Rights

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to per-
   tain to the implementation or use of the technology described in this
   document or the extent to which any license under such rights might
   or might not be available; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11.  Copies of claims of
   rights made available for publication and any assurances of licenses
   to be made available, or the result of an attempt made to obtain a
   general license or permission for the use of such proprietary rights
   by implementors or users of this specification can be obtained from
   the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

   The following eight (8) United States Patents related to time
   stamping, listed in chronological order, are known by the authors to
   exist at this time.  This may not be an exhaustive list.  Other
   patents MAY exist or be issued at any time.  This list is provided
   for informational purposes; to date, the IETF has not been notified
   of intellectual property rights claimed in regard to any of the




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


   specification contained in this document.  Should this situation
   change, the current status may be found at the online list of claimed
   rights (IETF Page of Intellectual Property Rights Notices).

   Implementers of this protocol SHOULD perform their own patent search
   and determine whether or not any encumbrances exist on their
   implementation.

   Users of this protocol SHOULD perform their own patent search and
   determine whether or not any encumbrances exist on the use of this
   standard.

# 5,001,752 Public/Key Date-Time Notary Facility
Filing date: October 13, 1989
Issued: March 19, 1991
Inventor: Addison M. Fischer

# 5,022,080 Electronic Notary
Filing date: April 16, 1989
Issued: June 4, 1991
Inventors: Robert T. Durst, Kevin D. Hunter

# 5,136,643 Public/Key Date-Time Notary Facility
Filing date: December 20, 1990
Issued: August 4, 1992
Inventor:  Addison M. Fischer
Note: This is a continuation of patent # 5,001,752.)

# 5,136,646 Digital Document Time-Stamping with Catenate Certificate
Filing date: August 2, 1990
Issued: August 4, 1992
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,136,647 Method for Secure Time-Stamping of Digital Documents
Filing date: August 2, 1990
Issued: August 4, 1992
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,373,561 Method of Extending the Validity of a Cryptographic
Certificate
Filing date: December 21, 1992
Issued: December 13, 1994
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,





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


# 5,422,953  Personal Date/Time Notary Device
Filing date: May 5, 1993
Issued: June 6, 1995
Inventor: Addison M. Fischer

# 5,781,629 Digital Document Authentication System
Filing date: February 21, 1997
Issued: July 14, 1998
Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,

6. References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
               RFC 2246, January 1999.

   [RFC2510]   Adams, C. and S. Farrell, "Internet X.509 Public Key
               Infrastructure, Certificate Management Protocols", RFC
               2510, March 1999.

   [RFC2459]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
               X.509 Public Key Infrastructure, Certificate and CRL
               Profile", RFC 2459, January 1999.

   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630,
               June 1999.

   [DSS]       Digital Signature Standard. FIPS Pub 186. National
               Institute of Standards and Technology. 19 May 1994.

   [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME", RFC
               2634, June 1999.

   [ISONR]     ISO/IEC 10181-5:  Security Frameworks in Open Systems.
               Non-Repudiation Framework. April 1997.

   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [SHA1]      Secure Hash Standard. FIPS Pub 180-1. National Institute
               of Standards and Technology. 17 April 1995.







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


7. Authors' Addresses

   Carlisle Adams
   Entrust, Inc.
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: [e-mail]


   Pat Cain
   BBN
   70 Fawcett Street
   Cambridge, MA 02138
   U.S.A.

   EMail: [e-mail]


   Denis Pinkas
   Integris
   68 route de Versailles
   B.P. 434
   78430 Louveciennes
   FRANCE

   EMail: [e-mail]


   Robert Zuccherato
   Entrust, Inc.
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: [e-mail]












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


APPENDIX A - Signature Time-stamp attribute using CMS

   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