Syntax for Binding Documents with Time-Stamps
RFC 5544

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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 document