Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000005347D
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2001-Aug-24
Document File: 27 page(s) / 55K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Adams: AUTHOR [+4]

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 6% of the total text.

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 operatio...