Syntax for Binding Documents with Time-Stamps
RFC 5544
Document | Type |
RFC - Informational
(February 2010; No errata)
Updated by RFC 5955
|
|
---|---|---|---|
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text pdf html bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5544 (Informational) | |
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | rfc-editor@rfc-editor.org |
Independent Submission A. Santoni Request for Comments: 5544 Actalis S.p.A. Category: Informational February 2010 ISSN: 2070-1721 Syntax for Binding Documents with Time-Stamps Abstract This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed. The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5544. IESG Note This RFC is not a candidate for any level of Internet Standard. The standards track specification RFC 4998, Evidence Record Syntax (ERS), specifies an alternative mechanism. Readers are encouraged to also review RFC 4998 when evaluating the suitability of this mechanism. Santoni Informational [Page 1] RFC 5544 February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ....................................................2 1.1. Conventions Used in This Document ..........................3 2. Syntax for TimeStampedData ......................................3 3. Compliance Requirements .........................................6 4. Recommended Processing ..........................................6 4.1. Generating a New TimeStampedData Structure .................7 4.2. Verifying an Existing TimeStampedData Structure ............8 4.3. Extending the Validity of an Existing TimeStampedData Structure ..................................9 5. Security Considerations .........................................9 6. Normative References ...........................................10 7. Informative References .........................................10 Appendix A. ASN.1 Module ..........................................11 Appendix B. Acknowledgments .......................................12 1. 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 time- stamp 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. Santoni Informational [Page 2] RFC 5544 February 2010 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 documentShow full document text