draft-ietf-pkix-rfc3161bis-00.txt

PKIX的RFC英文文档

   The "time-to-check-back" parameter is an unsigned 32-bit integer. It
   is the time in seconds indicating the minimum interval after which
   the client SHOULD check the status again.

   It provides an estimate of the time that the end entity should send
   its next pollReq.

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-reply 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 the reason code extension indicates keyCompromise then all 
      the tokens that have been signed with the corresponding private 
      key SHALL be considered as invalid.

      When the reason code extension indicates other reasons like 
      affiliationChanged (3) or cessationOfOperation (5), then this 
      reason code is definitive. However, should a key compromise 
      happen later on, it will not be reported by the CA. A good 
      practice will be for the TSA to warn its subscribers in advance 
      for a future revocation, so that they can apply another time-
      stamp token over the previous one and capture the CRL from 
      the CA that has issued the certificate to the previous time-
      stamping unit.



Adams, et al.               Standards Track                    [Page 13

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


   2. When the TSU 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
      TSU 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 TSU using that private key cannot be trusted
      anymore.  For this reason, it is imperative that the TSU'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 TSU MAY provide a means to discriminate between genuine and
      false backdated tokens.  Two time-stamp tokens from two different
      TSUs is another way to address this issue.

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

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

Adams, et al.               Standards Track                    [Page 14

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

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





Adams, et al.               Standards Track                    [Page 15

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


# 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.,

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


Adams, et al.               Standards Track                    [Page 16

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


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

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
   Bull 
   68 route de Versailles
   B.P. 434
   78430 Louveciennes
   FRANCE

   EMail: [e-mail]



Adams, et al.               Standards Track                    [Page 17

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


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

   EMail: [e-mail]














































Adams, et al.               Standards Track                    [Page 18

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


APPENDIX A - Signature Time-stamp attribute using CMS