Network Working Group D. Pinkas Internet-Draft Bull SAS Target Category: Standards Track February 2009 Will obsolete: 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) draft-ietf-pkix-rfc3161bis-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on August 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the format of a request sent to a Time Stamping Unit (TSU) in order to get a time-stamp token and of the response that is returned. It also establishes several security- relevant requirements for the operation of a time-stamping service, with regards to processing requests to generate responses. D.Pinkas Expires in July 2009 [Page 1] Internet-Draft Time-Stamp Protocol (TSP) February 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 3. The TSU . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements of the TSU . . . . . . . . . . . . . . . . . . 5 3.2. TSU Transactions . . . . . . . . . . . . . . . . . . . . . 5 3.3. Identification of the TSU . . . . . . . . . . . . . . . . . 6 3.4. Request and Response Formats . . . . . . . . . . . . . . . 7 3.4.1. Request Format . . . . . . . . . . . . . . . . . . . . 7 3.4.2. Response Format . . . . . . . . . . . . . . . . . . . . 9 4. Transports . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Time-Stamp Protocol Using E-mail . . . . . . . . . . . . . 14 4.2. File Based Protocol . . . . . . . . . . . . . . . . . . . 14 4.3. Socket Based Protocol . . . . . . . . . . . . . . . . . . 15 4.4. Time-Stamp Protocol via HTTP . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 8. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . 19 APPENDIX A - Signature Time-stamp attribute using CMS . . . . . . 20 APPENDIX B - Placing a Signature at a Particular Point in Time . 21 APPENDIX C - ASN.1 Module using 1988 Syntax (normative) . . . . . 22 APPENDIX D - Access descriptors for Time-Stamping. . . . . . . . .25 APPENDIX E - ASN.1 Module using 1988 Syntax (informative) . . . . 26 Legal Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction A time-stamping service supports assertions of proof that a datum existed before a particular time. This service is supported by one or more TSUs. A TSU is managed by a Time-Stamping Authority (TSA). It may be operated as a Trusted Third Party (TTP) service, though other operational models may be appropriate, e.g., an organization may require a TSU 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 annex B. D.Pinkas Expires in July 2009 [Page 2] Internet-Draft Time-Stamp Protocol (TSP) February 2009 In order to associate a datum with a particular point in time, a Time Stamp Unit (TSU) may need to be used. This unit managed by a Time- Stamping Authority provides a "proof-of-existence" for this particular datum at an instant in time. The TSU'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 TSU is beyond the scope of this document. This standard does not establish overall security requirements for TSA operation. For the description of Policy Requirements for Time-Stamping Authorities (TSAs), see RFC 3628 [RFC3628]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This specification obsoletes RFC 3161 [RFC3161]. Major differences from RFC 3161 [RFC3161] are summarized below: - the use of hash function different from SHA1 [SHA1] for CertID is now allowed through the support of RFC 5035 [ESSV2]. - the document has been aligned with RFC 3628 to make the difference between a time-stamping unit (TSU) and a TSA. - the document makes the difference between a time-stamping service and a time-stamping unit and allows a time-stamping service to support more than one time-stamping unit. - the format of the subject field of a TSU certificate is now defined. - informative references to ISO 18014-1 [ISO18014-1], ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been added. - a new normative ASN1 module has been added to refer to the ASN.1 modules from the latest RFCs. Since the ASN.1 is unchanged, the previous module has been kept for information. - an additional patent has been added to the list. D.Pinkas Expires in July 2009 [Page 3] Internet-Draft Time-Stamp Protocol (TSP) February 2009 2. Definitions and Abbreviations 2.1. Definitions For the purposes of the present document, the following terms and definitions apply: subscriber: entity requiring the services provided by a TSA and which has explicitly or implicitly agreed to its terms and conditions. time-stamp token: data object that binds a representation of a datum to a particular time, thus establishing evidence that the datum existed before that time. time-stamping authority: authority which issues time-stamp tokens. time-stamp policy: named set of rules that indicates the applicability of a time-stamp token to a particular community and/or class of application with common security requirements. time-stamping unit: set of hardware and software which is managed as a unit and has a single time-stamp token signing key active at a time. time-stamping service: a service providing time-stamp tokens by means of one or more time-stamping units managed by one time- stamping authority. Coordinated Universal Time (UTC): Time scale based on the second as defined in ITU-R Recommendation TF.460-5 [TF.460-5]. 2.2. Abbreviations For the purposes of the present document, the following abbreviations apply: TSA Time-Stamping Authority TSU Time-Stamping Unit TSS Time-Stamping Service TST Time-Stamp Token UTC Coordinated Universal Time 3. The TSU The TSU 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 3.4, and is from a supported subscriber. D.Pinkas Expires in July 2009 [Page 4] Internet-Draft Time-Stamp Protocol (TSP) February 2009 3.1. Requirements of the TSU The TSU is REQUIRED: 1. to use a trustworthy source of time aligned with UTC. 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. 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. 3.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 Service. As the second message, a Time Stamping Unit responds by sending a response (which is or includes a TimeStampResp, as defined below) to the requesting entity. D.Pinkas Expires in July 2009 [Page 5] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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. 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 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. 3.3. Identification of the TSU The name of the issuing TSU shall contain an appropriate subset of the following attributes (defined in ISO 9594-6 [ISO9594-6] and ITU-T Recommendation X.520 [X.520]): - countryName; - stateOrProvinceName; - organizationName; - commonName. The countryName, when applicable, identifies the name of the country where the TSA is established (which is not necessarily the name of the country where the time-stamping unit is located). The stateOrProvinceName is an optional component that identifies a geographical subdivision in which the TSA is established. The organizationName shall be present. It identifies the TSA responsible for managing the time-stamping unit. That name should be an officially registered name of the TSA. D.Pinkas Expires in July 2009 [Page 6] Internet-Draft Time-Stamp Protocol (TSP) February 2009 The commonName shall be present. It specifies an identifier for the time-stamping unit. Within the TSA, the attribute commonName uniquely identifies the time-stamping unit used. The TSU MUST sign each time-stamp message with a key reserved specifically for that purpose. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC5280] Section 4.2.1.12 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)} A TSS MAY have distinct TSUs, e.g., to accommodate different policies, different algorithms, different private key sizes or to increase the performance. 3.4. Request and Response Formats 3.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 [SHA1] or 32 bytes for SHA-256 [SHA256]). MessageImprint ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING } D.Pinkas Expires in July 2009 [Page 7] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 Server 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 TSS does not recognize the hash algorithm or knows that the hash algorithm is weak (a decision left to the discretion of each individual TSS), then the TSS 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 TSU's public key certificate that is referenced by the ESSCertID field inside a SigningCertificate attribute or by the ESSCertIDv2 field inside a SigningCertificateV2 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 [RFC5280]. 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 TSS (See Section 2.1). In situations where the TSS requires the identity of the requesting entity, alternate identification /authentication means have to be used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC5246]). D.Pinkas Expires in July 2009 [Page 8] Internet-Draft Time-Stamp Protocol (TSP) February 2009 3.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 [RFC4210] 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. 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 D.Pinkas Expires in July 2009 [Page 9] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 systemFailure (25) -- the request cannot be handled due to system failure } These are the only values of PKIFailureInfo that SHALL be supported. Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present. The statusString field of PKIStatusInfo MAY be used to include reason text such as "messageImprint field is not correctly formatted". A TimeStampToken is as follows. It is defined as a ContentInfo ([CMS]) and SHALL encapsulate a signed data content type. TimeStampToken ::= ContentInfo -- contentType is id-signedData ([CMS]) -- content is SignedData ([CMS]) The fields of type EncapsulatedContentInfo of the SignedData construct have the following meanings: eContentType is an object identifier that uniquely specifies the content type. For a time-stamp token it is defined as: id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4} 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 (either ESSCertID or ESSCertIDv2) of the TSU certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute. Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2 attribute MUST be used if any algorithm other than SHA-1 is used and SHOULD NOT be used for SHA-1. D.Pinkas Expires in July 2009 [Page 10] Internet-Draft Time-Stamp Protocol (TSP) February 2009 TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } The version field (currently v1) describes the version of the time- stamp token. Conforming time-stamping servers MUST be able to provide version 1 time-stamp tokens. Among the optional fields, only the nonce field MUST be supported. Conforming time-stamping requesters MUST be able to recognize version 1 time-stamp 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 TSA's 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 (unacceptedPolicy) 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 token may be used. * The availability of a time-stamp token 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 is an integer assigned by the TSU to each TimeStampToken. It MUST be unique for each TimeStampToken issued by a given TSU (i.e., the TSU name and serial number identify a unique TimeStampToken). It should be noticed that the property MUST be preserved even after a possible interruption (e.g., crash) of the service. D.Pinkas Expires in July 2009 [Page 11] Internet-Draft Time-Stamp Protocol (TSP) February 2009 genTime is the time at which the time-stamp token has been created by the TSA. It is expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone use. UTC is a time scale, based on the second (SI), as defined and recommended by the CCIR, and maintained by the Bureau International des Poids et Mesures (BIPM). A synonym is "Zulu" time which is used by the civil aviation and represented by the letter "Z" (phonetically "Zulu"). The ASN.1 GeneralizedTime syntax can include fraction-of-second details. Such syntax, without the restrictions from [RFC5280] Section 4.1.2.5.2, where GeneralizedTime is limited to represent the time with a granularity of one second, may be used here. GeneralizedTime values MUST include seconds. 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 [RFC5280]). The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z X.690 | ISO/IEC 8825-1 provides the following restrictions for a DER-encoding. The encoding MUST terminate with a "Z" (which means "Zulu" time). The decimal point element, if present, MUST be the point option ".". The fractional-seconds elements, if present, MUST omit all trailing 0's; if the elements correspond to 0, they MUST be wholly omitted, and the decimal point element also MUST 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 INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL } If either seconds, millis or micros is missing, then a value of zero MUST be taken for the missing field. D.Pinkas Expires in July 2009 [Page 12] Internet-Draft Time-Stamp Protocol (TSP) February 2009 By adding the accuracy value to the GeneralizedTime, an upper limit of the time at which the time-stamp token 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 time-stamp token has been created by the TSA can be obtained. accuracy can be decomposed in seconds, milliseconds (between 1-999) and microseconds (1-999), all expressed as integer. When the accuracy optional field is not present, then the accuracy may be available through other means, e.g., the TSAPolicyId. If the ordering field is missing, or if the ordering field is present and set to false, then the genTime field only indicates the time at which the time-stamp token has been created by the TSA. In such a case, the ordering of time-stamp tokens issued by the same TSA or different TSAs is only possible when the difference between the genTime of the first time-stamp token and the genTime of the second time-stamp token is greater than the sum of the accuracies of the genTime for each time-stamp token. If the ordering field is present and set to true, every time-stamp token from the same TSA can always be ordered based on the genTime field, regardless of the genTime accuracy. 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 a 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) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]). extensions is a generic way to add additional information in the future. Extensions is defined in [RFC5280]. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. 4. Transports There is no mandatory transport mechanism for TSU messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future. D.Pinkas Expires in July 2009 [Page 13] Internet-Draft Time-Stamp Protocol (TSP) February 2009 4.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. Two MIME objects are specified as follows: Content-Type: application/timestamp-query Content-Transfer-Encoding: base64 <> Content-Type: application/timestamp-reply Content-Transfer-Encoding: base64 <> These MIME objects can be respectively sent and received using common MIME processing engines and provides a simple Internet mail transport for Time-Stamp messages. For the application/timestamp-query and application/timestamp-reply MIME types, implementations SHOULD include the optional "name" and "filename" parameters. Including a file name helps preserve type information when time-stamp queries and replies are saved as files. When these parameters are included, a file name with the appropriate extension SHOULD be selected: MIME Type File Extension application/timestamp-query .TSQ application/timestamp-reply .TSR In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name. 4.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. A Time-Stamp Request SHOULD be contained in a file with file extension .tsq (like Time-Stamp Query). A Time-Stamp Response SHOULD be contained in a file with file extension .tsr (like Time-Stamp Reply). D.Pinkas Expires in July 2009 [Page 14] Internet-Draft Time-Stamp Protocol (TSP) February 2009 4.3. Socket Based Protocol The following simple TCP-based protocol is to be used for transport of TSU 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 TSS that can accept TSU messages on a well-defined port (IP port number 318). Typically an initiator binds to this port and submits the initial TSU message. The responder replies with a TSU message and/or with a reference number to be used later when polling for the actual TSU message response. If a number of TSU 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 TSU 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) D.Pinkas Expires in July 2009 [Page 15] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 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. 4.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 <> Content-Type: application/timestamp-reply <> 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. 5. IANA Considerations All actions related to IANA have been performed when RFC 3161 was issued. 6. Security Considerations This entire document concerns security considerations. When designing a TSS, the following considerations have been identified that have an impact upon the validity or "trust" in the time-stamp tokens. D.Pinkas Expires in July 2009 [Page 16] Internet-Draft Time-Stamp Protocol (TSP) February 2009 1. When a TSU shall not be used anymore, but the TSU private key has not been compromised, the TSU's certificate SHALL be revoked. When the reasonCode extension relative to the revoked certificate from the TSU 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 TSU 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. 2. When a 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 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 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. D.Pinkas Expires in July 2009 [Page 17] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 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. 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.2", RFC 5246, August 2008. [RFC4210] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 4210, September 2005. [RFC5280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 5280, May 2008. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 2004. [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [ESSV2] Schaad, J., Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility. RFC 5035. August 2007. D.Pinkas Expires in July 2009 [Page 18] Internet-Draft Time-Stamp Protocol (TSP) February 2009 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997. [ISO9594-6] ISO 9594-6: "Information technology - Open Systems Interconnection - The Directory: Selected attribute types". [RFC3161] Adams, C., Cain, P., Pinkas, D. and Zuccherato, R. "Time-Stamp Protocol (TSP)". RFC 3161. August 2001. [RFC3628] Pinkas, D., Pope, N. and Ross, J. "Policy Requirements for Time-Stamping Authorities". RFC 3628. November 2003. [SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995. [SHA256] Secure Hash Standard. FIPS Pub 180-2. National Institute of Standards and Technology. 2002. [X.520] ITU-T Recommendation X.520: "Information technology - Open Systems Interconnection - The Directory: Selected attribute types" 7.2. Informative references [ISO18014-1] Time-stamping services - Part 1. Framework. [ISO18014-2] Time-stamping services - Part 2. Mechanisms producing independent tokens. [ISO18014-3] Time-stamping services - Part 3. Mechanisms producing linked tokens. 8. Authors' Address Denis Pinkas Bull SAS Rue Jean Jaures B.P. 70 78340 Les Clayes sous Bois FRANCE EMail: Denis.Pinkas@bull.net D.Pinkas Expires in July 2009 [Page 19] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 The value of messageImprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signedData being time-stamped. D.Pinkas Expires in July 2009 [Page 20] Internet-Draft Time-Stamp Protocol (TSP) February 2009 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 before a particular point in time, from which the appropriate certificate status information (e.g., CRLs) MUST be checked. Signatures can only be verified according to a non-repudiation policy (also called signature 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 Service (TSS). The TSU 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 token 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 TSU in the TimeStampToken MUST be retrieved. 3) The certificate used by the signer MUST be identified and retrieved. 4) The date/time indicated by the TSU MUST be within 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 in the time-stamp token generated by the TSU. If all these conditions are successful, then the digital signature shall be declared as valid. D.Pinkas Expires in July 2009 [Page 21] Internet-Draft Time-Stamp Protocol (TSP) February 2009 APPENDIX C: ASN.1 Module using 1988 Syntax - Normative. This module references the ASN.1 modules that were valid at the time of publication of this RFC. It includes, for information, the OID of the module that defines ESSCertID and ESSCerIDv2. PKIXTSP2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp-2009(XX)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- The following modules present in RFC 5035 is necessary to produce -- either an ESSCertID or an ESSCertIDv2 field. -- FROM RFC 5035 -- ExtendedSecurityServices-2006 -- { iso(1) member-body(2) us(840) rsadsi(113549) -- pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } -- EXPORTS ALL -- IMPORTS -- FROM RFC 3280 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(18)} -- FROM RFC 3280 GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} -- FROM RFC 3852 ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)} -- FROM RFC 4210 PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp2000(16)} ; -- Locally defined OIDs -- D.Pinkas Expires in July 2009 [Page 22] Internet-Draft Time-Stamp Protocol (TSP) February 2009 -- eContentType for a time-stamp token id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4} -- 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 TSAPolicyId OPTIONAL, nonce INTEGER OPTIONAL, certReq BOOLEAN DEFAULT FALSE, extensions [0] IMPLICIT Extensions OPTIONAL } MessageImprint ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING } TSAPolicyId ::= OBJECT IDENTIFIER -- 2.4.2 TimeStampResp ::= SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } -- The status is based on the definition of status -- in section 3.2.3 of [RFC4210] PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } 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 } D.Pinkas Expires in July 2009 [Page 23] Internet-Draft Time-Stamp Protocol (TSP) February 2009 -- When the TimeStampToken is not present -- 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), -- 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 systemFailure (25) -- the request cannot be handled due to system failure } TimeStampToken ::= ContentInfo -- contentType is id-signedData as defined in [CMS] -- content is SignedData as defined in([CMS]) -- eContentType within SignedData is id-ct-TSTInfo -- eContent within SignedData is TSTInfo TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } Accuracy ::= SEQUENCE { seconds INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL } END D.Pinkas Expires in July 2009 [Page 24] Internet-Draft Time-Stamp Protocol (TSP) February 2009 APPENDIX D: Access descriptors for Time-Stamping A TSU's certificate MAY contain a Subject Information Access (SIA) extension in order to convey the method of contacting the TSU. In that case, the accessMethod field in this extension MUST contain the OID id-ad-timestamping. See section 4.2.2.2 from RFC 5280 [RFC5280]. The value of the accessLocation field defines the transport (e.g., HTTP) used to access the TSU and may contain other transport dependent information (e.g., a URL). D.Pinkas Expires in July 2009 [Page 25] Internet-Draft Time-Stamp Protocol (TSP) February 2009 APPENDIX E: ASN.1 Module using 1988 Syntax - Informative. This module references the ASN.1 modules that were valid at the time of publication of RFC 3161. It is kept for information purposes, since it should generate the same code as the new module. PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} DEFINITIONS IMPLICIT 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 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)} ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} ; -- Locally defined OIDs -- -- eContentType for a time-stamp token id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4} -- 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 TSAPolicyId OPTIONAL, nonce INTEGER OPTIONAL, certReq BOOLEAN DEFAULT FALSE, extensions [0] IMPLICIT Extensions OPTIONAL } D.Pinkas Expires in July 2009 [Page 26] Internet-Draft Time-Stamp Protocol (TSP) February 2009 MessageImprint ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashedMessage OCTET STRING } TSAPolicyId ::= OBJECT IDENTIFIER -- 2.4.2 TimeStampResp ::= SEQUENCE { status PKIStatusInfo, timeStampToken TimeStampToken OPTIONAL } -- The status is based on the definition of status -- in section 3.2.3 of [RFC4210] PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } 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 } -- When the TimeStampToken is not present -- 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), -- the requested TSA policy is not supported by the TSA unacceptedExtension (16), -- the requested extension is not supported by the TSA D.Pinkas Expires in July 2009 [Page 27] Internet-Draft Time-Stamp Protocol (TSP) February 2009 addInfoNotAvailable (17) -- the additional information requested could not be understood -- or is not available systemFailure (25) -- the request cannot be handled due to system failure } TimeStampToken ::= ContentInfo -- contentType is id-signedData as defined in [CMS] -- content is SignedData as defined in([CMS]) -- eContentType within SignedData is id-ct-TSTInfo -- eContent within SignedData is TSTInfo TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } Accuracy ::= SEQUENCE { seconds INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL } END D.Pinkas Expires in July 2009 [Page 28] Internet-Draft Time-Stamp Protocol (TSP) February 2009 Legal terms a. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. b. The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. c. Copies of Intellectual Property disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. d. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. e. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. f. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, D.Pinkas Expires in July 2009 [Page 29] Internet-Draft Time-Stamp Protocol (TSP) February 2009 whether published or posted by such Contributor, or included with or in such Contribution. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). D.Pinkas Expires in July 2009 [Page 30]