HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:29:41 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 06 Jan 2000 14:36:00 GMT ETag: "304c55-ab0e-3874a850" Accept-Ranges: bytes Content-Length: 43790 Connection: close Content-Type: text/plain Internet Draft C. Adams(Entrust Technologies) PKIX Working Group P. Cain (BBN) expires in six months D. Pinkas (Bull) R. Zuccherato(Entrust Technologies) January 2000 Internet X.509 Public Key Infrastructure Time Stamp Protocol (TSP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract A time stamping service allows to prove that a datum existed before a particular time and can be used by a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example of how to prove that a digital signature was generated during the validity period of the corresponding public key certificate is given in an annex. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. 1. Introduction 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. Adams, Cain, Pinkas, Zuccherato Page 1 Internet Draft Time Stamp Protocol (TSP) The TSAÆs role is to time stamp a datum to establish evidence indicating the time at which the datum existed. 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. 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 monotonically incrementing 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. 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 OID. 7. to examine the OID of the one-way collision resistant hash- function and to verify that the hashvalue 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. Adams, Cain, Pinkas, Zuccherato Page 2 Internet Draft Time Stamp Protocol (TSP) 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, 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 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, and/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. 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. The client MAY ignore this field if that is acceptable for the intended application. 2.3. Identification of the TSA The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. 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. A TSAÆs certificate MAY contain an Authority Information Access extension [RFC2459] in order to convey the method of contacting the TSA. The accessMethod field in this extension MUST contain the OID id-ad-timestamping: Adams, Cain, Pinkas, Zuccherato Page 3 Internet Draft Time Stamp Protocol (TSP) id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad-timestamping OBJECT IDENTIFIER ::= { id-ad 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). 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 [0] PolicyInformation OPTIONAL, nonce [1] Integer OPTIONAL, certReq [2] BOOLEAN DEFAULT FALSE, extensions [3] EXPLICIT Extensions OPTIONAL } The version field (currently v1) describes the version of the TimeStamp request. The messageImprint field SHALL 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 MUST be a known hash algorithm (one-way and collision resistant). The reqPolicy field, if included, indicates the policy under which the TimeStampToken should be provided. PolicyInformation is defined in Section 4.2.1.5 of [RFC2459]. The nonce, if included, allows 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 it is generated by the client only once (e.g. a 64 bit integer). In such a case the same nonce value shall be included in the response, otherwise the response shall be rejected. The certReq field allows to request the TSA's public key certificate in the response. That certificate must match with the ESSCertID attribute. The Adams, Cain, Pinkas, Zuccherato Page 4 Internet Draft Time Stamp Protocol (TSP) ESSCertID attribute, which is part of the signerInfo, is returned as an unsigned attribute from the CMS structure. That certificate value must be used to verify the digital signature of the TimeStamp token. If the certReq field is missing, the TSA's public key certificate is not provided. 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 uses the same error codes that are defined in section 3.2.3 of [RFC2510] but adds some new ones (14) to (17). When the PKIStatus contains the value zero a Time Stamp Token is present. Otherwise, the status indicates the reason why the time stamp request was rejected. PKIFailureInfo ::= BITSTRING { 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 } Adams, Cain, Pinkas, Zuccherato Page 5 Internet Draft Time Stamp Protocols (TSP) These are the only values of PKIFailureInfo that are supported. Compliant servers MUST NOT produce any other values. Compliant clients MAY ignore any other values. The statusString field of PKIStatusInfo MAY be used to include reason text such as "messageImprint field is not correctly formatted". If the error code returned is different from zero, then the TimeStampToken is not returned. A TimeStampToken is as follows. It is encapsulated as a SignedData construct [CMS] in the EncapsulatedContentInfo field. The signed-data content type from [CMS] shall have ASN.1 type SignedData. SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } SignerInfos ::= SET OF SignerInfo EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER The fields of type EncapsulatedContentInfo have the following meanings: eContentType is an object identifier that uniquely specifies the content type. For a time stamping token it is defined as: id-ct-TSTInfo OBJECT IDENTIFIER ::= {id-ct 4} with: id-ct OBJECT IDENTIFIER ::= { id-smime 1 } id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } eContent is the content itself, carried as an octet string. The eContent SHALL be the DER-encoded value of TSTInfo. The time stamp token MUST NOT contain any signatures other than the signature of the TSA. The certificate identifier (ESSCertID) of the TSA certificate shall be included as a signerInfo attribute. TSTInfo ::= SEQUENCE { version Integer { v1(1) }, policy PolicyInformation, Adams, Cain, Pinkas, Zuccherato Page 6 Internet Draft Time Stamp Protocols (TSP) messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber Integer, genTime GeneralizedTime, accuracy [0] Accuracy OPTIONAL, nonce [1] Integer OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it must have the same value. tsa [2] GeneralName OPTIONAL, extensions [3] EXPLICIT Extensions OPTIONAL } The version field (currently v1) describes the version of the Timestamp token. Conforming timestamping servers MUST be able to provide version 1 Timestamp tokens. Among the optional fields, only the nonce field MUST be supported. Conforming timestamping requesters MUST be able to recognize version 1 Timestamp tokens with all the optional fields present, but are not mandated to understand the semantics of any extension, if present. The policy field MUST indicate the TSAs policy under which the response was produced. If a similar field was present in the TimeStampReq, then it MUST have the same value, otherwise an error (badRequest) MUST be returned. This policy MAY include the following types of information (although this list is certainly not exhaustive): * The conditions under which the time stamp may be used. * The availability of a time-stamp log, to allow later verification that a time-stamp token is authentic. The messageImprint must have the same value as the similar field in TimeStampReq, provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm. The serialNumber field shall include a strictly monotonically increasing integer from one TimeStampToken to the next (e.g. 45, 236, 245, 1023, ...). This guarantees that each token is unique and allows to compare the ordering of two time stamps from the same TSA. This is useful in particular when two time stamps from the same TSA bear the same time. This field also provides the way to build a unique identifier to reference the token. It should be noticed that the monotonic property must remain valid even after a possible interruption (e.g. crash) of the service. genTime is the time at which the timestamp has been created by the TSA. The ASN.1 GeneralizedTime syntax can include fraction-of-second details. Such syntax, without the restrictions from [RFC 2459] Section 4.1.2.5.2, where GeneralizedTime is limited to represent time Adams, Cain, Pinkas, Zuccherato Page 7 Internet Draft Time Stamp Protocols (TSP) with one second, may to be used here. However, when there is no need to have a precision better than the second, then GeneralizedTime with a precision limited to one second should be used (as in [RFC 2459]). The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z X.690 | ISO/IEC 8825-1 provides the restrictions for a DER-encoding. The encoding shall terminate with a "Z". The decimal point element, if present, shall be the point option ".". The fractional-seconds elements, if present, shall omit all trailing 0's; if the elements correspond to 0, they shall be wholly omitted, and the decimal point element also shall be omitted. Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z" where "YYYYMMDD" represents the day following the midnight in question. Here are a few examples of valid representations: "19920521000000Z" "19920622123421Z" "19920722132100.3Z" accuracy represents the time deviation around the UTC time contained in GeneralizedTime. Accuracy ::= SEQUENCE { seconds [1] INTEGER OPTIONAL, millis [2] INTEGER (1..999) OPTIONAL, micros [3] INTEGER (1..999) OPTIONAL } By adding the accuracy value to the GeneralizedTime, an upper limit of the time at which the timestamp has been created by the TSA can be obtained. In the same way, by subtracting the accuracy to the GeneralizedTime, a lower limit of the time at which the timestamp has been created by the TSA can be obtained. accuracy is expressed as an integer, that can be decomposed either in seconds, milliseconds (between 1-999) or microseconds (1-999). When the accuracy optional field is not present, then the accuracy may be available through other means, e.g. the PolicyInformation. The nonce field MUST be present if it was present in the TimeStampReq. In such a case it MUST equal the value provided in the TimeStampReq structure. The purpose of the tsa field is to give an hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) which is part of the signerInfo (See Section 5 of [ESS]). Adams, Cain, Pinkas, Zuccherato Page 8 Internet Draft Time Stamp Protocols (TSP) extensions is a generic way to add additional information in the future. Extensions is defined in [RFC 2459]. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. 3. Transports There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms (e.g., based on TCP or HTTP) may be defined in the future. 3.1. Time Stamp Protocol Using E-mail This section specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via Internet mail. A simple MIME object is specified as follows: Content-Type: application/timestamp Content-Transfer-Encoding: base64 <> This MIME object can be sent and received using common MIME processing engines and provides a simple Internet mail transport for Time Stamp messages. 3.2. File Based Protocol A file containing a time stamp message MUST contain only the DER encoding of one TSA message, i.e. there MUST be no extraneous header or trailer information in the file. Such files can be used to transport time stamp messages using for example, FTP. 3.3. Socket Based Protocol The following simple TCP-based protocol is to be used for transport of TSA messages. This protocol is suitable for cases where an entity initiates a transaction and can poll to pick up the results. The protocol basically assumes a listener process on a TSA that can accept TSA messages on a well-defined port (IP port number 318). Typically an initiator binds to this port and submits the initial TSA message. The responder replies with a TSA message and/or with a reference number to be used later when polling for the actual TSA message response. Adams, Cain, Pinkas, Zuccherato Page 9 Internet Draft Time Stamp Protocols (TSP) If a number of TSA response messages are to be produced for a given request (say if a receipt must be sent before the actual token can be produced) then a new polling reference is also returned. When the final TSA response message has been picked up by the initiator then no new polling reference is supplied. The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient. The recipient responds with a similar message. A "direct TCP-based TSA message" consists of: length (32-bits), flag (8-bits), value (defined below) The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order. Message name flag value tsaMsg '00'H DER-encoded TSA message -- TSA message pollRep '01'H polling reference (32 bits), time-to-check-back (32 bits) -- poll response where no TSA message response ready; use polling -- reference value (and estimated time value) for later polling pollReq '02'H polling reference (32 bits) -- request for a TSA message response to initial message negPollRep '03'H '00'H -- no further polling responses (i.e., transaction complete) partialMsgRep '04'H next polling reference (32 bits), time-to-check-back (32 bits), DER-encoded TSA message -- partial response (receipt) to initial message plus new polling -- reference (and estimated time value) to use to get next part of -- response finalMsgRep '05'H DER-encoded TSA message -- final (and possibly sole) response to initial message errorMsgRep '06'H human readable error message -- produced when an error is detected (e.g., a polling reference -- is received which doesn't exist or is finished with) The sequence of messages that can occur is: a) entity sends tsaMsg and receives one of pollRep, negPollRep, partialMsgRep or finalMsgRep in response. b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep,finalMsgRep or errorMsgRep in response. The "time-to-check-back" parameter is a 32-bit integer, defined to be the number of seconds that have elapsed since midnight, January 1, 1970, coordinated universal time. It provides an estimate of the time that the end entity should send its next pollReq. Adams, Cain, Pinkas, Zuccherato Page 10 Internet Draft Time Stamp Protocols (TSP) 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. A simple MIME object is specified as follows. Content-Type: application/timestamp <> This MIME object 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 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 there is a reason to believe that the TSA can no longer be trusted but the TSA private key has not been compromised, the authorityÆs certificate SHALL be revoked. Thus, at any future time, the tokens signed with the corresponding key will not considered as valid. 2. When the TSA private key has been compromised, then the corresponding certificate SHALL be revoked. In this case, 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. A double time stamp 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. Adams, Cain, Pinkas, Zuccherato Page 11 Internet Draft Time Stamp Protocols (TSP) 4. An application using the TSA service 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. 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. 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 Adams, Cain, Pinkas, Zuccherato Page 12 Internet Draft Time Stamp Protocols (TSP) # 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 [RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols," RFC 2510, March 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC 2246, January 1999. [ESS] P. Hoffman, "Enhanced Security Services for S/MIME", draft-ietf- smime-ess-0X.txt, 1999 (work in progress). [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. Adams, Cain, Pinkas, Zuccherato Page 13 Internet Draft Time Stamp Protocols (TSP) [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 1999. [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997. 7. AuthorsÆ Addresses Carlisle Adams Pat Cain Entrust Technologies BBN 750 Heron Road 70 Fawcett Street Ottawa, Ontario Cambridge, MA 02138 K1V 1A7 U.S.A. CANADA pcain@bbn.com cadams@entrust.com Denis Pinkas Robert Zuccherato Bull S.A. Entrust Technologies Rue Jean Jaures 750 Heron Road B.P. 68 Ottawa, Ontario 78340 Les Clayes sous Bois K1V 1A7 FRANCE CANADA Denis.Pinkas@bull.net robert.zuccherato@entrust.com Adams, Cain, Pinkas, Zuccherato Page 14 Internet Draft Time Stamp Protocols (TSP) APPENDIX A - Signature Timestamp attribute using CMS One of the major use 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 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 Timestamp attribute that may be used to timestamp a digital signature. The following object identifier identifies the Signature Timestamp attribute: id-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa (2) id-aa-timeStampToken (14)} The Signature timestamp attribute value has ASN.1 type SignatureTimeStampToken: SignatureTimeStampToken ::= TimeStampToken The value of messageImprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signedData being timestamped. Adams, Cain, Pinkas, Zuccherato Page 15 Internet Draft Time Stamp Protocols (TSP) 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: 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 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 Time Stamping Token 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 inside 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. Adams, Cain, Pinkas, Zuccherato Page 16 Internet Draft Time Stamp Protocols (TSP) APPENDIX C MIME Registration To: ietf-types@iana.org Subject: Registration of MIME media type application/timestamp MIME media type name: application MIME subtype name: timestamp Required parameters: None Optional parameters: None Encoding considerations: binary or Base64 Security considerations: Carries a request for a timestamp and the response. The response will be cryptographically signed. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Time Stamp Protocols Applications which use this media type: Time Stamp clients Additional information: Magic number(s): None File extension(s): .TSA Macintosh File Type Code(s): none Person & email address to contact for further information: Robert Zuccherato Intended usage: COMMON Author/Change controller: Robert Zuccherato Adams, Cain, Pinkas, Zuccherato Page 17 Internet Draft Time Stamp Protocols (TSP) Appendix D: "Compilable" 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(X)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS 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, PolicyInformation 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)} PKIStatusInfo FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} SignedData FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} ESSCertID FROM ExtendedSecurityServices { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } -- Locally defined OIDs -- -- Authority Information Access for TSA id-ad-timestamping OBJECT IDENTIFIER ::= {id-ad 3} id-ad OBJECT IDENTIFIER ::= {id-pkix 48} id-pkix OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)} -- eContentType for a time stamping token id-ct-TSTInfo OBJECT IDENTIFIER ::= { id-ct 4 } id-ct OBJECT IDENTIFIER ::= { id-smime 1 } id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } Adams, Cain, Pinkas, Zuccherato Page 18 Internet Draft Time Stamp Protocols (TSP) -- 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 [0] PolicyInformation OPTIONAL, nonce [1] Integer OPTIONAL, certReq [2] BOOLEAN DEFAULT FALSE, extensions [3] EXPLICIT Extensions OPTIONAL } MessageImprint ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING } -- 2.4.2 TimeStampResp ::= SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } PKIFailureInfo ::= BITSTRING { 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 } TSTInfo ::= SEQUENCE { version Integer { v1(1) }, policy PolicyInformation, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber Integer, genTime GeneralizedTime, accuracy [0] Accuracy OPTIONAL, nonce [1] Integer OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it must have the same value. Adams, Cain, Pinkas, Zuccherato Page 19 Internet Draft Time Stamp Protocols (TSP) tsa [2] GeneralName OPTIONAL, extensions [3] EXPLICIT Extensions OPTIONAL } Accuracy ::= SEQUENCE { seconds [1] INTEGER OPTIONAL, millis [2] INTEGER (1..999) OPTIONAL, micros [3] INTEGER (1..999) OPTIONAL } APPENDIX E - Full Copyright Statement Copyright (C) The Internet Society 1999. 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 develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall 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. Adams, Cain, Pinkas, Zuccherato Page 20