diff options
Diffstat (limited to 'tests/external-data/rfc3161.txt')
| -rw-r--r-- | tests/external-data/rfc3161.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/tests/external-data/rfc3161.txt b/tests/external-data/rfc3161.txt new file mode 100644 index 00000000..628f300a --- /dev/null +++ b/tests/external-data/rfc3161.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. Adams +Request for Comments: 3161 Entrust +Category: Standards Track P. Cain + BBN + D. Pinkas + Integris + R. Zuccherato + Entrust + August 2001 + + + Internet X.509 Public Key Infrastructure + Time-Stamp Protocol (TSP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document describes the format of a request sent to a Time + Stamping Authority (TSA) and of the response that is returned. It + also establishes several security-relevant requirements for TSA + operation, with regards to processing requests to generate responses. + +1. Introduction + + A time-stamping service supports assertions of proof that a datum + existed before a particular time. A TSA may be operated as a Trusted + Third Party (TTP) service, though other operational models may be + appropriate, e.g., an organization might require a TSA for internal + time-stamping purposes. + + Non-repudiation services [ISONR] require the ability to establish the + existence of data before specified times. This protocol may be used + as a building block to support such services. An example of how to + prove that a digital signature was generated during the validity + period of a public key certificate is given in an annex. + + + + + +Adams, et al. Standards Track [Page 1] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in + uppercase, as shown) are to be interpreted as described in [RFC2119]. + + In order to associate a datum with a particular point in time, a Time + Stamp Authority (TSA) may need to be used. This Trusted Third Party + provides a "proof-of-existence" for this particular datum at an + instant in time. + + The TSA's role is to time-stamp a datum to establish evidence + indicating that a datum existed before a particular time. This can + then be used, for example, to verify that a digital signature was + applied to a message before the corresponding certificate was revoked + thus allowing a revoked public key certificate to be used for + verifying signatures created prior to the time of revocation. This + is an important public key infrastructure operation. 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. + + This standard does not establish overall security requirements for + TSA operation, just like other PKIX standards do not establish such + requirements for CA operation. Rather, it is anticipated that a TSA + will make known to prospective clients the policies it implements to + ensure accurate time-stamp generation, and clients will make use of + the services of a TSA only if they are satisfied that these policies + meet their needs. + +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 unique integer for each newly generated time-stamp + token. + + + +Adams, et al. Standards Track [Page 2] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 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 + 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 + + + +Adams, et al. Standards Track [Page 3] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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, 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 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. + +2.3. Identification of the TSA + + The TSA MUST sign each time-stamp message with a key reserved + specifically for that purpose. A TSA MAY have distinct private keys, + e.g., to accommodate different policies, different algorithms, + different private key sizes or to increase the performance. 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. + + The following object identifier identifies the KeyPurposeID having + value id-kp-timeStamping. + + id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1) + identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) + kp (3) timestamping (8)} + +2.4. Request and Response Formats + +2.4.1. Request Format + + A time-stamping request is as follows: + +TimeStampReq ::= SEQUENCE { + version INTEGER { v1(1) }, + messageImprint MessageImprint, + --a hash algorithm OID and the hash value of the data to be + + + +Adams, et al. Standards Track [Page 4] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + --time-stamped + reqPolicy TSAPolicyId OPTIONAL, + nonce INTEGER OPTIONAL, + certReq BOOLEAN DEFAULT FALSE, + extensions [0] IMPLICIT Extensions OPTIONAL } + + The version field (currently v1) describes the version of the Time- + Stamp request. + + The messageImprint field SHOULD contain the hash of the datum to be + time-stamped. The hash is represented as an OCTET STRING. Its + length MUST match the length of the hash value for that algorithm + (e.g., 20 bytes for SHA-1 or 16 bytes for MD5). + + MessageImprint ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier, + hashedMessage OCTET STRING } + + The hash algorithm indicated in the hashAlgorithm field SHOULD be a + known hash algorithm (one-way and collision resistant). That means + that it SHOULD be one-way and collision resistant. The Time Stamp + Authority SHOULD check whether or not the given hash algorithm is + known to be "sufficient" (based on the current state of knowledge in + cryptanalysis and the current state of the art in computational + resources, for example). If the TSA does not recognize the hash + algorithm or knows that the hash algorithm is weak (a decision left + to the discretion of each individual TSA), then the TSA 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 TSA's public key + certificate that is referenced by the ESSCertID identifier inside a + SigningCertificate attribute in the response MUST be provided by the + TSA in the certificates field from the SignedData structure in that + response. That field may also contain other certificates. + + + +Adams, et al. Standards Track [Page 5] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + If the certReq field is missing or if the certReq field is present + and set to false then the certificates field from the SignedData + structure MUST not be present in the response. + + The extensions field is a generic way to add additional information + to the request in the future. Extensions is defined in [RFC 2459]. + 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 is based on the definition of status in section 3.2.3 + of [RFC2510] as follows: + + PKIStatusInfo ::= SEQUENCE { + status PKIStatus, + statusString PKIFreeText OPTIONAL, + failInfo PKIFailureInfo OPTIONAL } + + When the status contains the value zero or one, a TimeStampToken MUST + be present. When status contains a value other than zero or one, a + TimeStampToken MUST NOT be present. One of the following values MUST + be contained in status: + + PKIStatus ::= INTEGER { + granted (0), + -- when the PKIStatus contains the value zero a TimeStampToken, as + requested, is present. + grantedWithMods (1), + -- when the PKIStatus contains the value one a TimeStampToken, + with modifications, is present. + rejection (2), + waiting (3), + revocationWarning (4), + + + +Adams, et al. Standards Track [Page 6] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + -- 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 + 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]) + + + + +Adams, et al. Standards Track [Page 7] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 (ESSCertID) of the + TSA certificate MUST be included as a signerInfo attribute inside a + SigningCertificate attribute. + +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. + + + + + +Adams, et al. Standards Track [Page 8] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 TSA to each + TimeStampToken. It MUST be unique for each TimeStampToken issued by + a given TSA (i.e., the TSA 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. + + 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 [RFC 2459] + 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 [RFC 2459]). + + The syntax is: YYYYMMDDhhmmss[.s...]Z + Example: 19990609001326.34352Z + + X.690 | ISO/IEC 8825-1 provides the following restrictions for a + DER-encoding. + + + + + +Adams, et al. Standards Track [Page 9] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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. + + 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. + + + + +Adams, et al. Standards Track [Page 10] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 [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 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. + + Two MIME objects are specified as follows: + + Content-Type: application/timestamp-query + Content-Transfer-Encoding: base64 + <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>> + + Content-Type: application/timestamp-reply + Content-Transfer-Encoding: base64 + <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>> + + 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. + + + +Adams, et al. Standards Track [Page 11] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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. + +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. + + 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). + +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. + + 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. + + + + +Adams, et al. Standards Track [Page 12] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 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. + + + +Adams, et al. Standards Track [Page 13] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +3.4. Time-Stamp Protocol via HTTP + + This subsection specifies a means for conveying ASN.1-encoded + messages for the protocol exchanges described in Section 2 and + Appendix D via the HyperText Transfer Protocol. + + Two MIME objects are specified as follows. + + Content-Type: application/timestamp-query + + <<the ASN.1 DER-encoded Time-Stamp Request message>> + + Content-Type: application/timestamp-reply + + <<the ASN.1 DER-encoded Time-Stamp Response message>> + + These MIME objects can be sent and received using common HTTP + processing engines over WWW links and provides a simple browser- + server transport for Time-Stamp messages. + + Upon receiving a valid request, the server MUST respond with either a + valid response with content type application/timestamp-response or + with an HTTP error. + +4. Security Considerations + + This entire document concerns security considerations. When + designing a TSA service, the following considerations have been + identified that have an impact upon the validity or "trust" in the + time-stamp token. + + 1. When a TSA shall not be used anymore, but the TSA private key has + not been compromised, the authority's certificate SHALL be + revoked. When the reasonCode extension relative to the revoked + certificate from the TSA is present in the CRL entry extensions, + it SHALL be set either to unspecified (0), affiliationChanged (3), + superseded (4) or cessationOfOperation (5). In that case, at any + future time, the tokens signed with the corresponding key will be + considered as invalid, but tokens generated before the revocation + time will remain valid. When the reasonCode extension relative to + the revoked certificate from the TSA is not present in the CRL + entry extensions, then all the tokens that have been signed with + the corresponding key SHALL be considered as invalid. For that + reason, it is recommended to use the reasonCode extension. + + + + + + + +Adams, et al. Standards Track [Page 14] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 2. When the TSA private key has been compromised, then the + corresponding certificate SHALL be revoked. In that case, the + reasonCode extension relative to the revoked certificate from the + TSA may or may not be present in the CRL entry extensions. When + it is present then it SHALL be set to keyCompromise (1). Any + token signed by the TSA using that private key cannot be trusted + anymore. For this reason, it is imperative that the TSA's private + key be guarded with proper security and controls in order to + minimize the possibility of compromise. In case the private key + does become compromised, an audit trail of all tokens generated by + the TSA MAY provide a means to discriminate between genuine and + false backdated tokens. Two time-stamp tokens from two different + TSAs is another way to address this issue. + + 3. The TSA signing key MUST be of a sufficient length to allow for a + sufficiently long lifetime. Even if this is done, the key will + have a finite lifetime. Thus, any token signed by the TSA SHOULD + be time-stamped again (if authentic copies of old CRLs are + available) or notarized (if they aren't) at a later date to renew + the trust that exists in the TSA's signature. time-stamp tokens + could also be kept with an Evidence Recording Authority to + maintain this trust. + + 4. A client application using only a nonce and no local clock SHOULD + be concerned about the amount of time it is willing to wait for a + response. A `man-in-the-middle' attack can introduce delays. + Thus, any TimeStampResp that takes more than an acceptable period + of time SHOULD be considered suspect. Since each transport method + specified in this document has different delay characteristics, + the period of time that is considered acceptable will depend upon + the particular transport method used, as well as other environment + factors. + + 5. If different entities obtain time-stamp tokens on the same data + object using the same hash algorithm, or a single entity obtains + multiple time-stamp tokens on the same object, the generated + time-stamp tokens will include identical message imprints; as a + result, an observer with access to those time-stamp tokens could + infer that the time-stamps may refer to the same underlying data. + + + + + + + + + + + + +Adams, et al. Standards Track [Page 15] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 6. Inadvertent or deliberate replays for requests incorporating the + same hash algorithm and value may happen. Inadvertent replays + occur when more than one copy of the same request message gets + sent to the TSA because of problems in the intervening network + elements. Deliberate replays occur when a middleman is replaying + legitimate TS responses. In order to detect these situations, + several techniques may be used. Using a nonce always allows to + detect replays, and hence its use is RECOMMENDED. Another + possibility is to use both a local clock and a moving time window + during which the requester remembers all the hashes sent during + that time window. When receiving a response, the requester + ensures both that the time of the response is within the time + window and that there is only one occurrence of the hash value in + that time window. If the same hash value is present more than + once within a time window, the requester may either use a nonce, + or wait until the time window has moved to come back to the case + where the same hash value appears only once during that time + window. + +5. Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain to the implementation or use of the technology described in this + document or the extent to which any license under such rights might + or might not be available; neither does it represent that it has made + any effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and standards- + related documentation can be found in BCP-11. Copies of claims of + rights made available for publication and any assurances of licenses + to be made available, or the result of an attempt made to obtain a + general license or permission for the use of such proprietary rights + by implementors or users of this specification can be obtained from + the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + The following eight (8) United States Patents related to time + stamping, listed in chronological order, are known by the authors to + exist at this time. This may not be an exhaustive list. Other + patents MAY exist or be issued at any time. This list is provided + for informational purposes; to date, the IETF has not been notified + of intellectual property rights claimed in regard to any of the + + + + +Adams, et al. Standards Track [Page 16] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + specification contained in this document. Should this situation + change, the current status may be found at the online list of claimed + rights (IETF Page of Intellectual Property Rights Notices). + + Implementers of this protocol SHOULD perform their own patent search + and determine whether or not any encumbrances exist on their + implementation. + + Users of this protocol SHOULD perform their own patent search and + determine whether or not any encumbrances exist on the use of this + standard. + +# 5,001,752 Public/Key Date-Time Notary Facility +Filing date: October 13, 1989 +Issued: March 19, 1991 +Inventor: Addison M. Fischer + +# 5,022,080 Electronic Notary +Filing date: April 16, 1989 +Issued: June 4, 1991 +Inventors: Robert T. Durst, Kevin D. Hunter + +# 5,136,643 Public/Key Date-Time Notary Facility +Filing date: December 20, 1990 +Issued: August 4, 1992 +Inventor: Addison M. Fischer +Note: This is a continuation of patent # 5,001,752.) + +# 5,136,646 Digital Document Time-Stamping with Catenate Certificate +Filing date: August 2, 1990 +Issued: August 4, 1992 +Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. +(assignee) Bell Communications Research, Inc., + +# 5,136,647 Method for Secure Time-Stamping of Digital Documents +Filing date: August 2, 1990 +Issued: August 4, 1992 +Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. +(assignee) Bell Communications Research, Inc., + +# 5,373,561 Method of Extending the Validity of a Cryptographic +Certificate +Filing date: December 21, 1992 +Issued: December 13, 1994 +Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. +(assignee) Bell Communications Research, Inc., + + + + + +Adams, et al. Standards Track [Page 17] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +# 5,422,953 Personal Date/Time Notary Device +Filing date: May 5, 1993 +Issued: June 6, 1995 +Inventor: Addison M. Fischer + +# 5,781,629 Digital Document Authentication System +Filing date: February 21, 1997 +Issued: July 14, 1998 +Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr. +(assignee) Surety Technologies, Inc., + +6. References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", + RFC 2246, January 1999. + + [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key + Infrastructure, Certificate Management Protocols", RFC + 2510, March 1999. + + [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet + X.509 Public Key Infrastructure, Certificate and CRL + Profile", RFC 2459, January 1999. + + [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, + June 1999. + + [DSS] Digital Signature Standard. FIPS Pub 186. National + Institute of Standards and Technology. 19 May 1994. + + [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC + 2634, June 1999. + + [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. + Non-Repudiation Framework. April 1997. + + [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute + of Standards and Technology. 17 April 1995. + + + + + + + +Adams, et al. Standards Track [Page 18] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +7. Authors' Addresses + + Carlisle Adams + Entrust, Inc. + 1000 Innovation Drive + Ottawa, Ontario + K2K 3E7 + CANADA + + EMail: cadams@entrust.com + + + Pat Cain + BBN + 70 Fawcett Street + Cambridge, MA 02138 + U.S.A. + + EMail: pcain@bbn.com + + + Denis Pinkas + Integris + 68 route de Versailles + B.P. 434 + 78430 Louveciennes + FRANCE + + EMail: Denis.Pinkas@bull.net + + + Robert Zuccherato + Entrust, Inc. + 1000 Innovation Drive + Ottawa, Ontario + K2K 3E7 + CANADA + + EMail: robert.zuccherato@entrust.com + + + + + + + + + + + + +Adams, et al. Standards Track [Page 19] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +APPENDIX A - Signature Time-stamp attribute using CMS + + One of the major uses of time-stamping is to time-stamp a digital + signature to prove that the digital signature was created before a + given time. Should the corresponding public key certificate be + revoked this allows a verifier to know whether the signature was + created before or after the revocation date. + + A sensible place to store a time-stamp is in a [CMS] structure as an + unsigned attribute. + + This appendix defines a Signature Time-stamp attribute that may be + used to time-stamp a digital signature. + + The following object identifier identifies the Signature Time-stamp + attribute: + + id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 } + + The Signature time-stamp attribute value has ASN.1 type + SignatureTimeStampToken: + + SignatureTimeStampToken ::= TimeStampToken + + 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. + +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: + + + +Adams, et al. Standards Track [Page 20] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 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 TSA 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 TSA 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 by + the TSA. + + If all these conditions are successful, then the digital signature + shall be declared as valid. + +APPENDIX C: 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(13)} + +DEFINITIONS IMPLICIT TAGS ::= + +BEGIN + +-- EXPORTS ALL -- + +IMPORTS + + + + +Adams, et al. Standards Track [Page 21] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + 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 } + +MessageImprint ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier, + hashedMessage OCTET STRING } + +TSAPolicyId ::= OBJECT IDENTIFIER + + +-- 2.4.2 + +TimeStampResp ::= SEQUENCE { + status PKIStatusInfo, + timeStampToken TimeStampToken OPTIONAL } + + + +Adams, et al. Standards Track [Page 22] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +-- The status is based on the definition of status +-- in section 3.2.3 of [RFC2510] + +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. + 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 + + + +Adams, et al. Standards Track [Page 23] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + -- 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 + +APPENDIX D: Access descriptors for Time-Stamping. + + [This annex describes an extension based on the SIA extension that + will be defined in the "son-of-RFC2459". Since at the time of + publication of this document, "son-of-RFC2459" is not yet available, + its description is placed in an informative annex. The contents of + this annex will eventually become incorporated into the son-of- + RFC2459 document, at which time this annex will no longer be needed. + A future version of this document will likely omit this annex and + refer to son-of-RFC2459 directly.] + + A TSA's certificate MAY contain a Subject Information Access (SIA) + extension (son of RFC2459) in order to convey the method of + contacting the TSA. The accessMethod field in this extension MUST + contain the OID id-ad-timestamping: + + The following object identifier identifies the access descriptors for + time-Stamping. + + + +Adams, et al. Standards Track [Page 24] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + + id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1) + identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) + ad (48) timestamping (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). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Adams, et al. Standards Track [Page 25] + +RFC 3161 Time-Stamp Protocol (TSP) August 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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 + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Adams, et al. Standards Track [Page 26] + |