IETF RFC 5544 PDF

Introduction

Time-stamping has become the standard technique for proving the existence of a document before a certain point in time. Several legislations around the world embrace the concept and provide for time-stamping services, mainly for the purpose of extending the validity of signed documents. However, while time-stamping enhances digital signatures, its value does not depend on them. It can clearly be useful to time-stamp a document even if it is not signed. And it can also be useful, or even mandatory in some cases, to timestamp a signed document in its entirety, regardless of how many signatures it contains.

When a time-stamp is related to a digital signature, there already exists a way to keep the two pieces together: RFC 3161 [TSP] describes how one or more TimeStampTokens can be included in a SignerInfo structure as unsigned attributes. On the other hand, there is no standard way to keep together a time-stamped document, whether signed or not, and the related time-stamps.

In such cases, two approaches are typically being adopted:

o time-stamps are kept as separate files (keeping track of what time-stamps belong to what documents is up to the user);

o an ad hoc solution is adopted for specific applications, e.g., a ZIP archive or a proprietary "envelope" of some kind.

Both solutions impede interoperability, which is the objective of this memo.

This document describes a simple syntax for binding one document (actually, any kind of file) to the corresponding temporal evidence; the latter is typically represented by one or more RFC 3161 TimeStampTokens. Additional types of temporal evidence, e.g., an RFC 4998 EvidenceRecord [ERS], are also supported via an "open" syntax. However, for the sake of interoperability, the emphasis in this document is on TimeStampTokens.

The proposed syntax is broadly based on the Cryptographic Message Syntax (CMS) defined in RFC 5652 [CMS].