Internet Draft C. Adams(Entrust Technologies)
PKIX Working Group P. Cain (BBN)
expires in six months D. Pinkas (Bull)
R. Zuccherato(Entrust Technologies)
June 1999
Internet X.509 Public Key Infrastructure
Time Stamp Protocol (TSP)
<draft-ietf-pkix-time-stamp-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was
generated during the validity period of the corresponding public key
certificate is given in an annex. In order to get additional
confidence about the information returned by the TSA, an optional
Temporal Data Authority (TDA) can add data to the response that
proves in addition that a datum existed before a particular
unpredictable event.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
Adams, Cain, Pinkas, Zuccherato Page 1
Internet Draft Time Stamp Protocol (TSP)
1. Introduction
In order to associate a datum with a particular point in time, a
Time Stamp Authority (TSA) may need to be used. This Trusted Third
Party provides a ½proof-of-existence© for this particular datum at an
instant in time. A TSA may also be used when a trusted time reference
is required and when the local clock is either unavailable or cannot be
trusted. The TSAÆs role is to time stamp a datum to establish evidence
indicating the time at which the datum existed. This can then be used,
for example, to verify that a digital signature was applied to a message
before the corresponding certificate was revoked thus allowing a revoked
public key certificate to be used for verifying signatures created prior
to the time of revocation. This is an important public key
infrastructure operation. The TSA can also be used to indicate the time
of submission when a deadline is critical, or to indicate the time of
transaction for entries in a log. An exhaustive list of possible uses
of a TSA is beyond the scope of this document.
The Temporal Data Authority (TDA) is a TTP that creates a temporal data
token (See Appendix C). This temporal data token associates a datum
with a particular event and provides supplementary evidence for the time
included in the time stamp token.
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 provide a trustworty source of time.
2. not to include any identification of the requesting entity in
the time stamp tokens.
3. to include a monotonically incrementing value of the time of day
for each newly generated time stamp token.
4. to produce a time stamp token upon receiving a valid request
from the requester, when it is possible.
5. to include within each time stamp token an identifier to
uniquely indicate the security policy under which
the token was created.
6. to only time stamp a hash representation of the datum, i.e. a
data imprint associated with a one-way collision resistant hash-
function OID.
7. to examine the OID of the one-way collision resistant hash-
function and to verify that this function is ½sufficient© (see
Section 2.4).
Adams, Cain, Pinkas, Zuccherato Page 2
Internet Draft Time Stamp Protocol (TSP)
8. not to examine the imprint being time stamped in any way.
9. 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.
10. to include supplementary temporal information in the time stamp
token (from TDAÆs) if asked by the requester. 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 TimeStampToken, as defined below) to
the requesting entity.
Upon receiving the response (which is or includes a TimeStampResp,
as defined below), the requesting entity verifies the status error
returned in the response and if no error is present verifies the
various fields contained in the TimeStampToken and the validity of the
digital signature of the TimeStampToken. In particular, it verifies
that what was time stamped corresponds to what was requested to be
time stamped. The requester SHALL verify that the TimeStampToken
contains the correct certificate identifier of the TSA, the correct
data imprint and the correct hash algorithm OID. It SHALL then verify
the timeliness of the response by verifying either the time included
in the response against a local trusted time reference, if one is
available, and/or the value of the nonce (large random number with a
high probability that it is generated by the client only once)
included in the response against the value included in the request.
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. If TemporalDataTokenÆs
are included in the TimeStampToken, then these SHOULD also be verified
as was the TimeStampToken (see Appendix C).
The client application SHOULD check the policy field to determine
whether or not the policy under which the token was issued is acceptable
for the application. The client MAY ignore this field if that is
acceptable for the intended application.
2.3. Identification of the TSA
The TSA MUST sign all time stamp messages with one or more keys reserved
specifically for that purpose. The corresponding certificate MUST
contain the extended key usage field extension as defined in [RFC2459]
Section 4.2.1.14 with KeyPurposeID having value id-kp-timeStamping.
This extension MUST be critical.
Adams, Cain, Pinkas, Zuccherato Page 3
Internet Draft Time Stamp Protocol (TSP)
A TSAÆs certificate MAY contain an Authority Information Access
extension [RFC2459] in order to convey the method of contacting the
TSA. The accessMethod field in this extension MUST contain the OID
id-ad-timestamping:
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-timestamping OBJECT IDENTIFIER ::= { id-ad X }
The value of the accessLocation field defines the transport (e.g. HTTP)
used to access the TSA and may contain other transport dependent
information(e.g. a URL).
2.4. Request and Response Formats
A time stamping request is as follows:
TimeStampReq ::= SEQUENCE {
version Integer { v1(0) },
reqPolicy [0] PolicyInformation OPTIONAL,
nonce [1] Integer OPTIONAL,
--MUST be present if messageImprint is not present
messageImprint [2] MessageImprint OPTIONAL
--a hash algorithm OID and the hash value of the data to be
--time stamped
tdas [3] SEQUENCE OF GeneralName OPTIONAL,
}
The reqPolicy field, if included, indicates the policy under which the
TimeStampToken should be provided. PolicyInformation is defined in
Section 4.2.1.5 of [RFC2459].
The messageImprint field MAY be absent in situations where the requester
requires a verifiable source of time that is independent of any
particular datum.
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }
The hash algorithm indicated in the hashAlgorithm field MUST be a strong
hash algorithm. That means that it MUST be one-way and collision
resistant. It is up to the Time Stamp Authority to decide whether or
not the given hash algorithm is ½sufficient© (based on the current state
of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).
The hashedMessage 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 MD-5).
The tdas field identifies those TDAs which are requested to provide
supplementary temporal evidence in the time stamp token. (See Appendix
C.)
Adams, Cain, Pinkas, Zuccherato Page 4
Internet Draft Time Stamp Protocol (TSP)
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, it is suggested that alternate identification means be used
(e.g. CMS encapsulation [CMS] or TLS authentication [RFC2246]).
A time stamping response is as follows:
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo,
timeStampToken TimeStampToken OPTIONAL
}
The status is using the same error codes that are defined in
section 3.2.3 of [RFC2510].
When the PKIStatusInfo contains the value zero a Time Stamp Token is
present. Otherwise, the status indicates the reason why the time stamp
request was rejected.
PKIFailureInfo ::= BITSTRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSAs time source is not available
tdaNotAvailable (15)
-- at least one of the TDAs that were requested isnÆt available
}
These are the only values of PKIFailureInfo that are supported.
Compliant servers MUST NOT produce any other values.
Compliant clients MAY ignore any other values.
The statusString field of PKIStatusInfo MAY be used to include reason
text such as ½messageImprint field is not correctly formatted©.
If the error code returned is different from zero, then the
TimeStampToken is not returned.
A TimeStampToken is as follows. It is encapsulated as a SignedData
construct [CMS] in the EncapsulatedContentInfo field. The signed-data
content type from [CMS] shall have ASN.1 type SignedData.
Adams, Cain, Pinkas, Zuccherato Page 5
Internet Draft Time Stamp Protocols (TSP)
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT
CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The fields of type EncapsulatedContentInfo have the following meanings:
eContentType is an object identifier that uniquely specifies the content
type. For a time stamping token it is defined as:
id-ct-TSTInfo OBJECT IDENTIFIER ::= {id-ct 4}
with:
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
eContent is the content itself, carried as an octet string. The
eContent content type shall have ASN.1 type TSTInfo.
The time stamp token MUST NOT contain any signatures other than the
signature of the TSA. The certificate identifier of the TSA
certificate shall be included as a signed attribute.
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
TSTInfo ::= SEQUENCE {
version Integer { v1(0) },
policy PolicyInformation,
tsa [0] GeneralName OPTIONAL,
tstTime TSTTime,
nonce [1] Integer OPTIONAL,
--MUST be present if the token was produced in response to a
--TimeStampReq and the nonce was present in the TimeStampReq
--this field MUST have the same value as the similar field
--in TimeStampReq
Adams, Cain, Pinkas, Zuccherato Page 6
Internet Draft Time Stamp Protocols (TSP)
messageImprint [2] MessageImprint OPTIONAL,
--MUST be present if the similar field in TimeStampReq is
--present
--MUST have the same value as the similar field in
--TimeStampReq
serialNumber [3] Integer OPTIONAL,
tsaFreeData [4] OCTET STRING OPTIONAL,
--contains supplementary information from the TSA
tdaTokens [5] SEQUENCE OF TemporalDataToken
OPTIONAL
}
The policy field MUST indicate the TSAs policy under which the response
was produced. This policy MAY include the following types of
information (although this list is certainly not exhaustive):
* The method used to define valid message imprint digests. The TSA
would be guaranteeing that the digest was considered usable at the
time of the time-stamp.
* The availability of a time-stamp log, to allow later verification
that a time-stamp token is authentic.
* A certification of the timestamp accuracy.
The purpose of the tsa field is to give an hint in identifying the
name of the TSA. If present, it MUST correspond to one of the subject
names included in the certificate that is to be used to verify the
token. However, the actual identification of the entity which signed
the response will always occur through the use of the certificate
identifier (ESSCertID Attribute) which is part of the signerInfo
(See Section 5 of [ESS]).
TSTTime ::= SEQUENCE {
genTime GeneralizedTime,
fractionOfSecond BIT STRING,
precisionFactor INTEGER
}
GeneralizedTime shall be used as described in [RFC2459] Section
4.1.2.5.2. GeneralizedTime only represents time with one second
granularity.
The value used for the fractionOfSecond field MUST be monotonically
increasing within the second regardless of the value the precision
field indicates.
The precisionFactor field is an 8 bit signed integer giving an upper
bound on the difference between the timestamp and UTC when the
timestamp was issued. The actual precision of the clock is calculated
as power(2, precisionFactor). A negative precisionFactor value
produces a precision as a fraction of a second.
Adams, Cain, Pinkas, Zuccherato Page 7
Internet Draft Time Stamp Protocols (TSP)
For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
(31ms). This precisionFactor would account for the 50-Hz (20ms) or
60-Hz (16.67ms) power-frequency clock that is closely synchronized
with UTC, for example. For a typical computerÆs clock synchronized
with UTC once a day, the precisionFactor might have value 3 (8 s).
Note that this method defines a precision of a clock as 'being around
the value', not as an exact figure. The actual method and frequency
of synchronising the clock with UTC time, as well as the
characteristics of the clock itself, define the deviation from UTC.
As this protocol is not conceived to be used as a source of precise
timing, that information is not present in the stamp. However, the
TSAs policy MAY contain necessary details for interested parties.
The fractionOfSecond field is a 32 bit unsigned integer indicating
the fraction of second; i.e. with the most significant bit indicating
500 ms, the second 250 ms, and so on.
The serialNumber field, if present, shall include a strictly
monotonically increasing Integer from one TimeStampToken to the next.
This will guarantee that each token is unique and provides for
additional auditing capabilities. It should be noticed that this
property must remain valid even after a possible interruption (e.g.
crash) of the service.
There may be situations where the TSA MAY wish to include supplementary
non-time stamp related information in the time stamp token (e.g. billing
information, usage statistics, etc.). The format of this information is
TSA dependant and the value MAY be placed in the tsafreedata field as an
OCTET STRING. Conformant clients MAY ignore this field, if present.
TemporalDataToken is defined in Appendix C of this document. The
tdaTokens field contains the supplementary evidence requested in the
TimeStampReq.
3. Transports
There is no mandatory transport mechanism for TSA messages in this
document. All mechanisms described below are optional.
3.1. File Based Protocol
A file containing a time stamp message MUST contain only the DER
encoding of one TSA message, i.e. there MUST be no extraneous header or
trailer information in the file. Such files can be used to transport
time stamp messages using for example, FTP.
3.2. 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 which
can accept TSA messages on a well-defined port (port number 318).
Adams, Cain, Pinkas, Zuccherato Page 8
Internet Draft Time Stamp Protocols (TSP)
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.
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 which can occur is:
a) entity sends tsaMsg and receives one of pollRep, negPollRep,
partialMsgRep or finalMsgRep in response.
b) end entity sends pollReq message and receives one of negPollRep,
partialMsgRep,finalMsgRep or errorMsgRep in response.
The "time-to-check-back" parameter is a 32-bit integer, defined to be
the number of seconds which have elapsed since midnight, January 1,
1970, co-ordinated universal time.
Adams, Cain, Pinkas, Zuccherato Page 9
Internet Draft Time Stamp Protocols (TSP)
It provides an estimate of the time that the end entity should send
its next pollReq.
3.3. 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 C via
Internet mail.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
This MIME object can be sent and received using common MIME processing
engines and provides a simple Internet mail transport for Time Stamp
messages.
3.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 C via the
HyperText Transfer Protocol.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
<<the ASN.1 DER-encoded Time Stamp message>>
This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Time Stamp messages.
Upon receiving a valid request, the server MUST respond with either a
valid response with content type application/timestamp or with an HTTP
error.
4. Security Considerations
This entire document concerns security considerations.
When designing a TSA/TDA service, the following considerations have been
identified that have an impact upon the validity or ½trust© in the time
stamp token.
1. When there is a reason to believe that the TSA/TDA can no longer
be trusted, the authorityÆs certificate MUST be revoked. Thus,
at any future time the tokens signed with the corresponding key
will not be valid.
Adams, Cain, Pinkas, Zuccherato Page 10
Internet Draft Time Stamp Protocols (TSP)
2. The TSA/TDA private key is compromised and the corresponding
certificate is revoked. In this case, any token signed by the
TSA/TDA using that private key cannot be trusted. For this
reason, it is imperative that the TSA/TDAÆ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/TDA MAY provide a means to discriminate between genuine
and false backdated tokens.
3. The TSA/TDA 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/TDA 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/TDAÆs signature.
Time stamp tokens could also be kept with an Evidence Recording
Authority to maintain this trust.
4. An application using the TSA/TDA service SHOULD be concerned
about the amount of time it is willing to wait for a response.
A `man-in-the-middleÆ attack can introduce delays. Thus, any
TimeStampToken that takes more than an acceptable period of time
SHOULD be considered suspect.
5. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from
the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Adams, Cain, Pinkas, Zuccherato Page 11
Internet Draft Time Stamp Protocols (TSP)
The following United States Patents related to time stamping, listed in
chronological order, are known by the authors to exist at this time.
This may not be an exhaustive list. Other patents MAY exist or be
issued at any time. Implementers of this protocol SHOULD perform their
own patent search and determine whether or not any encumbrances exist
on their implementation.
# 5,001,752 Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M. Fischer
# 5,022,080 Electronic Notary
(issued) June 4, 1991
(inventors) Robert T. Durst, Kevin D. Hunter
# 5,136,643 Public/Key Date-Time Notary Facility
(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
(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
(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
(issued) December 13, 1994
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,422,953 Personal Date/Time Notary Device
(issued) June 6, 1995
(inventor) Addison M. Fischer
# 5,781,629 Digital Document Authentication System
(issued) July 14, 1998
(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,
6. References
[RFC2510] C. Adams, S. Farrell, ½Internet X.509 Public Key
Infrastructure, Certificate Management Protocols,© RFC 2510, March 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Adams, Cain, Pinkas, Zuccherato Page 12
Internet Draft Time Stamp Protocols (TSP)
[RFC2246] T. Dierks, C. Allen, ½The TLS Protocol, Version 1.0,© RFC
2246, January 1999.
[ESS] P. Hoffman, ½Enhanced Security Services for S/MIME©, draft-ietf-
smime-ess-0X.txt, 1999 (work in progress).
[CMS] R. Housley, ½Cryptographic Message Syntax©, draft-ietf-smime-cms-
0X.txt, 1999 (work in progress).
[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, ½Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile,© RFC 2459, January
1999.
[PKCS9] RSA Laboratories, ½The Public-Key Cryptography Standards
(PKCS)©, RSA Data Security Inc., Redwood City, California, November
1993 Release.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework.
7. AuthorsÆ Addresses
Carlisle Adams Pat Cain
Entrust Technologies BBN
750 Heron Road 70 Fawcett Street
Ottawa, Ontario Cambridge, MA 02138
K1V 1A7 U.S.A.
CANADA pcain@bbn.com
cadams@entrust.com
Denis Pinkas Robert Zuccherato
Bull S.A. Entrust Technologies
Rue Jean Jaures 750 Heron Road
B.P. 68 Ottawa, Ontario
78340 Les Clayes sous Bois K1V 1A7
FRANCE CANADA
Denis.Pinkas@bull.net robert.zuccherato@entrust.com
Adams, Cain, Pinkas, Zuccherato Page 13
Internet Draft Time Stamp Protocols (TSP)
APPENDIX A - Storage of Data and Token
A time stamp token is meaningless without its associated data. Thus, a
method is required to allow users to store the data and token together
securely. They MAY be stored as a PKCS #7 SignedData object as
described in [CMS]. That is, the contentType is signedData and
contentInfo is Data, which contains the datum associated with the time
stamp token. The SignedData object is signed by the person storing the
data and token. This signature is to be used only for storage and for
verifying the integrity of the token and data. Anyone using the token
and data at some future time must verify the data and token at that
time. This is just a method for keeping the two pieces of information
together, with some integrity.
For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
type. This attribute type specifies the time stamp token, which MUST be
included as a signed attribute of the SignedData object. The time stamp
token attribute type has ASN.1 type TimeStampToken (as defined in
Section 2.4 of this document). A time stamp token attribute MUST have a
single attribute value.
The object identifier id-aa-timeStampToken identifies the time stamp
token attribute type.
id-aa-timeStampToken OBJECT IDENTIFIER ::= { id-aa 13 }
id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
APPENDIX B - Placing a Signature At a Particular Point in Time
We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from
which the appropriate certificate status information (e.g. CRLs) MUST be
checked. This application is intended to be used in conjunction with
evidence generated using a digital signature mechanism.
Signatures can only be verified according to a non-repudiation policy.
This policy MAY be implicit or explicit (i.e., indicated in the
evidence provided by the signer). The non-repudiation policy can
specify, among other things, the time period allowed by a signer to
declare the compromise of a signature key used for the generation of
digital signatures. Thus a signature may not be guaranteed to be valid
until the termination of this time period.
To verify a digital signature, the following basic technique may be
used:
A) Time stamping information needs to be obtained soon after the
signature has been produced (e.g. within a few minutes or hours).
1) The signature is presented to the Time Stamping Authority (TSA).
The TSA then returns a TimeStampToken (TST) upon that signature.
2) The invoker of the service must then verify that the
TimeStampToken is correct.
Adams, Cain, Pinkas, Zuccherato Page 14
Internet Draft Time Stamp Protocols (TSP)
B) The validity of the digital signature may then be verified in the
following way:
1) the Time stamp itself must be verified and it must be verified
that it applies to the signature of the signer.
2) The date/time indicated by the TSA in the Time Stamping Token
must be retrieved.
3) The certificate used by the signer must be identified
and retrieved.
4) The date/time indicated by the TSA must be inside the validity
period of the signer's certificate.
5) The revocation information about that certificate, at the
date/time of the Time Stamping operation, must be retrieved.
6) Should the certificate be revoked, then the date/time of
revocation shall be later than the date/time indicated by
the TSA
If all these conditions are successful, then the digital signature
shall be declared as valid.
Adams, Cain, Pinkas, Zuccherato Page 15
Internet Draft Time Stamp Protocols (TSP)
Appendix C - The TDA
The Temporal Data Authority is a TTP that creates a temporal data
token. This temporal data token associates a datum with a particular
event and provides supplementary evidence for the time included in the
time stamp token. For example, a TDA could associate the datum with
the most recent closing value of the Dow Jones Average. The temporal
data with which the datum is associated SHOULD be unpredictable in
order to prevent forward dating of tokens. Authentic values of this
data SHOULD also be available from a large number of trustworthy sources
in order to make collusion or corruption of data more difficult. For a
list of possible types of temporal data, see Appendix D.
C.1. Requirements of the TDA
The TDA is REQUIRED:
1. to only provide a trustworthy source of temporal data.
2. not to examine the imprint being time stamped.
3. to include the current data associated with a specific
unpredictable event in each temporal data token.
4. to produce a temporal data token upon receiving a valid request
from the TSA, when this is possible.
5. to only produce a temporal data token on a hash representation
of the datum.
6. to sign each temporal data message using a key generated
exclusively for this purpose and have this property of the key
indicated on the corresponding certificate.
C.2. TDA Transactions
As the first message of this mechanism, the TSA requests a temporal data
token by sending a request (which is or includes a TemporalDataReq, as
defined below) to the TDA. As the second message, the TDA responds by
sending a response (which is or includes a TemporalDataToken, as defined
below) to the TSA.
C.3. Verifying a TemporalDataToken
The TSA is REQUIRED to verify the structure of the TemporalDataToken.
It MUST verify the digital signature in the TemporalDataToken and also
verify that what was signed corresponds to what was requested to be
signed. The requester SHOULD verify that the TemporalDataToken contains
the correct TDA name, the correct data imprint and the correct hash
algorithm OID. It SHOULD also verify the timeliness of the response by
verifying the value of the nonce included in the response against the
value included in the request (exact match needed). Since the TDAÆ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.
In order to verify the TemporalData inside a TemporalDataToken, it is
necessary to know the form of the temporal data that the TDA has
included in the token.
Adams, Cain, Pinkas, Zuccherato Page 16
Internet Draft Time Stamp Protocols (TSP)
The TSA is not required to verify the TemporalData. However, either the
entity requesting a Time Stamping Token or an entity verifying a Time
Stamping Token containing temporal information MAY be interested in such
a verification.
In the first case, it is unlikely that the temporal information will be
available ahead of time and thus the entity requesting a Time Stamping
Token MAY need to enter into an online protocol with the TDA, or some
other entity, to obtain it. A secure link with that trusted source MAY
be necessary, i.e. the communication channel or the information itself
must be authenticated and integrity protected. Such a protocol is TDA
dependent and is outside the scope of this document.
In the second case, if the verification occurs some time after the Time
Stamping Token has been produced, then it is possible to rely on an
authentic source (e.g. a newspaper or a CD-ROM) to verify it against.
The exact method of verification is TDA dependent and is thus outside
the scope of this document.
C.4. Identification of the TDA
The TDA MUST sign all temporal data tokens with one or more keys
reserved specifically for that purpose. The corresponding certificate
MUST contain the extended key usage field extension as defined in
[RFC2459] Section 4.2.1.14 with KeyPurposeID having value
id-kp-temporalDataAuthority. This extension MUST be critical.
id-kp-temporalDataAuthority OBJECT IDENTIFIER ::= {id-kp 9}
-- Providing temporal data in support of time stamping services. Key
-- usage bits that may be consistent: digitalSignature,
-- nonRepudiation
A TDAÆs certificate MAY contain an Authority Information Access
extension [RFC2459] in order to convey the method of contacting the TDA.
The accessMethod field in this extension MUST contain the OID id-ad-
temporaldata:
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-temporaldata OBJECT IDENTIFIER ::= { id-ad X }
The value of the accessLocation field defines the transport (e.g. HTTP)
used to access the TDA and may contain other transport dependent
information(e.g. a URL).
C.5. Request and Token Formats
A temporal data request from a TSA is as follows.
TemporalDataReq ::= SEQUENCE {
version Integer { v1(0) },
nonce [0] Integer OPTIONAL,
--MUST be present if the TimeStampToken being produced
--is in response to a TimeStampReq which contains a nonce
--MUST be the same value as the corresponding field in
--TimeStampReq
Adams, Cain, Pinkas, Zuccherato Page 17
Internet Draft Time Stamp Protocols (TSP)
messageImprint [1] MessageImprint OPTIONAL
--MUST be present if the similar field in TimeStampReq is
--present
--a hash of the data to be time stamped, MUST be the same
--value as the corresponding field in TimeStampReq
}
A TemporalDataToken is as follows. It is encapsulated as a SignedData
construct [CMS]. The content is of type TDTInfo.
TemporalDataToken ContentInfo ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
--{pkcs-7 2}, SignedData
content [0] SEQUENCE {
version INTEGER,
digestAlgorithms AlgorithmIdentifier,
contentInfo SEQUENCE {
contentType OBJECT IDENTIFIER,
--{id-ct 5}, id-ct-TDTInfo
content TDTInfo }
certificate [0] Certificate,
signerInfos SignerInfos } }
The temporal data token must not contain any signatures other than the
signature of the TDA. In some environments, the CA might not perform a
proof-of-possession of the private key when issuing certificates. In
these instances, either the certificate of the TDA, or the certificate
issuer and serial number shall be included as a signed attribute.
TDTInfo ::= SEQUENCE {
version Integer { v1(0) },
tda [0] GeneralName OPTIONAL,
nonce [1] Integer OPTIONAL,
--MUST be present if the similar field in TemporalDataReq is
--present
--MUST have the same value as the corresponding field in
--TemporalDataReq
temporalData TemporalData,
messageImprint [2] MessageImprint OPTIONAL,
--MUST be present if the similar field in TemporalDataReq is
--present
--MUST have the same value as the corresponding field in
--TemporalDataReq
serialNumber [3] Integer OPTIONAL
}
The temporalData field contains the actual temporal data that will
be used as substantiating evidence in the time stamp token.
TemporalData ::= SEQUENCE {
format OBJECT IDENTIFIER,
rawdata ANY DEFINED BY format }
Adams, Cain, Pinkas, Zuccherato Page 18
Internet Draft Time Stamp Protocols (TSP)
The serialNumber field, if present, shall include a strictly
monotonically increasing Integer from one TemporalDataToken to the next.
This will guarantee that each token is unique.
The purpose of the tda field is to identify the name of the TDA. 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 which signed the response will always occur
through certificate validation, of course. This field MAY be omitted if
the Signing Certificate Attribute has been included as an authenticated
attribute. (See Section 5 of [ESS].) It MUST be present if the Signing
Certificate Attribute is not used to identify the TDA.
Appendix D û MIME Registration
To: ietf-types@iana.org
Subject: Registration of MIME media type application/timestamp
MIME media type name: application
MIME subtype name: timestamp
Required parameters: None
Optional parameters: None
Encoding considerations: binary or Base64
Security considerations: Carries a request for a timestamp and the
response. The response will be cryptographically signed.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Time Stamp
Protocols
Applications which use this media type: Time Stamp clients
Additional information:
Magic number(s): None
File extension(s): .TSA
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Robert Zuccherato <robert.zuccherato@entrust.com>
Intended usage: COMMON
Author/Change controller:
Robert Zuccherato <robert.zuccherato@entrust.com>
Adams, Cain, Pinkas, Zuccherato Page 19
Internet Draft Time Stamp Protocols (TSP)
Appendix E - Full Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process shall be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Adams, Cain, Pinkas, Zuccherato Page 20
Datatracker
Report a datatracker bug
draft-ietf-pkix-time-stamp-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3161.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |