URL: https://www.ietf.org/rfc/rfc3161.txt
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
<
