Network Working Group C. Adams
Request for Comments: 3161 Entrust
Category: Standards Track P. Cain
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 (C) The Internet Society (2001). All Rights Reserved.
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.
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
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
Adams, et al. Standards Track [Page 2]RFC 3161 Time-Stamp Protocol (TSP) August 2001