Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
RFC 3161

Document Type RFC - Proposed Standard (August 2001; Errata)
Updated by RFC 5816
Authors Robert Zuccherato  , Patrick Cain  , Carlisle Adams  , Denis Pinkas 
Last updated 2020-01-21
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3161 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           C. Adams
Request for Comments: 3161                                       Entrust
Category: Standards Track                                        P. Cain
                                                               D. Pinkas
                                                           R. Zuccherato
                                                             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.


   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


   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

   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

   6.    to only time-stamp a hash representation of the datum, i.e., a
Show full document text