[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4810

Internet Draft                                          Carl Wallace
draft-ietf-ltans-reqs-00.txt                Orion Security Solutions
February 2004                                          Ralf Brandner
Expires August 2004                   InterComponentWare AG Walldorf
                                                     Ulrich Pordesch
                                                Fraunhofer Institute
                                              Secure Telecooperation

                  Long-term Archive Service Requirements

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced or made obsolete by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   In many scenarios, users need to be able to ensure and prove the
   existence and integrity of data, especially digitally signed data, in
   a common and reproducible way over a long and possibly undetermined
   period of time.  This document specifies the technical requirements
   for a long-term archive service to support such scenarios.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Wallace                    Expires July 2004                   [Page 1]

                Long-term archive service requirements   January 2004

Table of Contents

   1. Introduction...................................................2
   2. Terminology....................................................3
   3. Application scenarios and general requirements.................4
      3.1 Long-term archive problems and tasks.......................4
      3.2 Long-term Archive Service..................................5
      3.3 Instances and overall architecture.........................7
   4. Long-term Archive Service functional and quality requirements..8
   5. Long-term Archive Service data structure requirements..........9
   6. Long-term Archive Service Protocol requirements...............10
   7. Security Considerations.......................................11
   8. Acknowledgements..............................................11
   9. Normative References..........................................11
   10. Authors' Addresses...........................................13

1.   Introduction

   Various scenarios require the ability to preserve digital data and
   its value as evidence for long periods of time.  If data is important
   and will be needed in the future, it is necessary to store it in a
   highly secure and persistent way. If the data is needed as evidence
   in court, it may be necessary to prove that the existed at a certain
   time in the past and has not been modified since then.  If data is
   signed or timestamped it is necessary to prove that it existed before
   cryptographic algorithms used to generate its signatures became weak
   or the certificates expired or were revoked.

   A long-term archive service aids in the preservation of data over
   long periods of time.  In particular, it periodically performs
   activities to preserve the non-repudiation of existence and integrity
   as well as ensuring the availability of data.

   A variety of technical and operational means are required to achieve
   this goal and technical issues beyond cryptography, such as storage
   media lifetime, disaster planning, changes in processing or software
   technology, etc., as well as legal issues must be addressed.

   It is anticipated that a timestamp will be obtained for data submitted
   to a long-term archive service.  Thus, for all types of data, i.e.
   signed and unsigned, will require preservation of evidence value by
   the long-term archive service.

   Any digital signature that may need to be verified at points in time
   well into the future, e.g. past the certificate validity period or
   past the cryptoperiod of the signature private key, is a candidate
   for preservation using a long-term archive service.  Examples include

Wallace                    Expires July 2004                   [Page 2]

                Long-term archive service requirements   January 2004

   signed contracts or agreements, wills, property deeds, CRLs and
   timestamps over any type of data.  The service will provide means to
   prove the integrity and time of existence of the data at a given
   point in time.  It must be provable that the data is reliable,
   because it existed at a point in time in the past when e.g. the
   embedded hash and signature algorithms were still strong and the
   included certificates were not revoked.

   This document aims to identify the technical requirements for a long-
   term archive service.  The
   requirements analysis is divided into two parts.
   The first part presents several application
   scenarios.  The second part addresses more specific requirements for
   functions of the service, data structures to support preservation of
   data integrity using cryptographic mechanisms and at least protocol
   requirements for interacting with a long-term archive service.

   Operational requirements, such as storage media concerns, individual
   legal requirements and questions dealing with accounting and billing
   techniques are not addressed by this document. However, the
   transaction data and protocols must allow information to be carried
   either directly or indirectly to facilitate association of
   transactions with some accounting and billing mechanism, e.g.
   identifiers for individual clients and/or large customers.

2. Terminology

   Arbitrator: Person, who has to be convinced of various aspects of
   authenticity (originator, integrity, time of existence) of archived
   data objects.

   Archived data object:  Data unit that is archived and has to be
   preserved for a long time by the Long-term Archive Service.

   Archive package: Collection of information including archived data
   objects and the associated evidence record.

   Evidence:  Information that may be used to resolve a dispute about
   various aspects of authenticity of archived data objects.

   Evidence record: Collection of evidence compiled for one or more
   given archived data objects over time.  An evidence record may
   include timestamps and additional verification data, like
   certificates, revocation information, trust anchors, policy details,
   role information, etc.

   Originator: Role (person or process) who produces, and possibly
   signs, a data object that is to be archived.  The Originator does
   not necessarily generate or request generation of an evidence record
   for the data.

 Wallace                    Expires July 2004                   [Page 3]

                Long-term archive service requirements   January 2004

   Timestamp: A signed confirmation generated by a Time Stamping
   Authority (TSA) that a data item existed at a certain time.
   [RFC3161] specifies a good structure for timestamps and a protocol
   for communicating with a Timestamp Authority (TSA).

   Trusted Archiving:  A process that includes storing of data objects
   for long periods of time preserving its integrity, periodic
   generation of timestamps and collection of evidence in support of
   long-term preservation of data integrity.

   Trusted archive authority (TAA):   A service responsible for
   preserving data for long periods of time, including generation and
   collection of evidence, storage of archived data objects and
   evidence, etc.  A.K.A. Long-term archive service.

   User: Role (person or process), who submit data objects for
   archiving, request archive packages and verify the evidence of an
   archived data object using the associated evidence record,
   optionally including the verification of any signatures within the
   archived data object itself.

3.  Application scenarios and general requirements

3.1 Long-term archive problems and tasks

   A Long-term Archive Service has to be designed to cover several
   problems in the area of long-term archiving of data objects.  The
   following sections describe some of these problems.

3.1.1 Availability and integrity of data for long periods of time

   Individuals, companies and organisations are facing the problem of
   how to store electronic documents in a safe way for sometimes even
   undetermined spans of time.  Examples include digital contracts, tax
   declarations or electronic birth certificates.  These documents need
   special care in order to ensure persistent readability, permanent
   availability, integrity and proper protection of confidentiality.
   While some large organisations may be capable of supporting
   appropriate backup, archive and protection mechanisms citizens and
   small enterprises lack the technical prerequisites for this task.
   Service providers offering external services for such documents are
   thus needed.

3.1.2 Demonstration of proof of existence and integrity for court

   Many archived documents are valuable and may be used as evidence in
   court at some point in the future, e.g. to prove entitlements to

Wallace                    Expires July 2004                   [Page 4]

                Long-term archive service requirements   January 2004

   benefits or damages.  In this case, it might be required to prove
   that these documents existed at a certain time in the past and where
   not modified since that time.

3.1.3 Preservation of evidence for signed or timestamped data

   Archived data objects may contain digital signatures or time stamps
   to be able to prove the origin and the time of existence of these
   objects and signatures.  In the course of time the value of evidence
   of these signatures or timestamps can decrease or can get lost for
   many reasons:

      - Revocation information is no longer available due to the
   decommissioning of a CA or OCSP responder;

      - Lack of availability of certificates necessary to verify a
   digital signature;

      - Expiration or Revocation of a certificate associated with a
   digital signature;

      - Cryptanalytic or computational advances make it possible to
   forge documents and signatures or to compute secret keys.

   In order to avoid problems in case of disputes in the future it is
   necessary to preserve a digitally signed document, as well as
   certificates, revocations lists, OCSP responses and time stamps, even
   if these elements are not included in the signed document itself.
   Preservation may be achieved by periodic review of evidence.  Upon
   review, updated evidence may be obtained and stored or additional
   cryptographic mechanisms may be applied, e.g. a new timestamp
   obtained possibly using a stronger algorithm.

   By periodically inspecting and acting upon stored evidence, it is
   possible to generate a cryptographically protected history for a data
   item that contains no periods of time during which an algorithm was
   thought to be weak, an authority thought to be compromised, etc.

3.2    Long-term Archive Service

   A Long-term Archive Service is to be designed to solve essential
   parts of these problems by providing a specialized service:

   - The Long-term Archive Service is to store archived data objects
   over a long, optionally undefined, period of time. Recovery methods,
   redundant storage and disaster management and other measures have to
   guarantee the availability of the data objects.

Wallace                    Expires July 2004                   [Page 5]

                Long-term archive service requirements   January 2004

   - The Long-term Archive Service provides material needed to prove the
   existence and integrity of data objects for users as well as in
   court.  These means especially are time-stamps, periodically
   generated during the archiving period of the data objects. Additional
   verification data, to verify these time-stamps after a long period of
   time (CRLS, OCSP responses and certificates) need also be provided.

   - The Long-term Archive Service provides means to preserve the value
   of evidence of the archived data objects that are signed. These means
   are also time-stamps but with regard to possible special legal
   requirements for the use as mechanism for the renewal of signatures.
   By using these means a signature application can verify that a
   document, which contains signatures, existed before algorithms got
   weak or certificates got invalid.

   A Long-term Archive Service is to not be designed to solve all
   thinkable problems of long-term-verification of digital signatures.
   It does not provide data necessary to verify signatures which are
   part of the archived data object itself.  This has to be done by
   verifiers using PKI-Services like SCVP (Simple Certificate Validation
   Protocol) or DVCS (Data Validation and Certification Server).  This
   is done, in part, so the archive service can operate without
   knowledge of numerous signed data formats, document formats, etc.  It
   also does not provide any means to integrate verification data in
   data objects and verify embedded signatures.  This has to be done on
   the basis of other specifications, like RFC 3029 and with regard to
   specifications of document formats.  Of course it is recommended to
   use such specifications together with a Long-term Archive Service.

   Several application scenarios providing one or more of these basic
   service features are to be supported, including:

   - Archive service assuring long-term Non-Repudiation

      Long-term Archive Service stores data objects like signed or
   unsigned documents for identified and authenticated users.  It
   generates time stamps for these data objects and obtains necessary
   verification data over a given time or until a request of deletion by
   this authorized user is sent.

   - Pure long-term non-repudiation Service

      Long-term Archive Service only guarantees non-repudiation of
   existence of data.  It periodically generates time stamps and obtains
   additional verification data for a given period of time.  It stores
   data objects (e.g. documents, but also relevant parts of documents
   containing signatures) locally only for the purpose of non-
   repudiation.  It is not a document-archive for users and therefore
   does not provide retrieval of documents and no deletion of data
   objects.  Therefore it does not need any access control.

Wallace                    Expires July 2004                   [Page 6]

                Long-term archive service requirements   January 2004

3.3    Instances and overall architecture

   The basic functions of a Long-term Archive Service are realized by
   several instances:

   |             |
   |     User    |
   |             |
     ----------- Long-term Archive Protocol
   |             |
   |    TAA      |
   |             |
     ----------- Time Stamp Protocol
   |             |
   |    TSA      |
   |             |

   Users transfer the data objects that shall be archived at the Trusted
   Archive Authority (TAA) using their application of choice.  After
   that, the user or application can request archive packages containing
   the stored data objects and the associated evidence record.  This is
   done by using the Long-term Archive Service Protocol and the data
   format of archive package to be specified.  The TAA stores the
   documents, and obtains necessary verification data, especially time
   stamps consulting a Time Stamp Authority using a special Protocol,
   especially Time Stamp Protocol (RFC 3161).  TAA also uses other
   protocols (e.g. SCVP) to get additional verification data necessary
   to verify generated time-stamps.

   A TAA may also provide the functions of a TSA, but separation must be
   possible.  A TAA may store the archived data objects locally or may
   use external archive services.

   Long-term Archive Service may allow for relays using Long-term
   Archive Protocol. The use of external archive services may be also
   possible. But Relaying must be transparent to the client.

Wallace                    Expires July 2004                   [Page 7]

                Long-term archive service requirements   January 2004

   A TAA may be a server within an enterprise network communicating with
   local archive servers and other applications or an external service
   accessible via internet.

4.   Long-term Archive Service functional and quality requirements

   A Long-term Archive Service MUST provide following basic functions:

      - Accept data objects or groups of data objects for preservation;

      - Store submitted data objects for a given period of time;

      - Generate, store and maintain evidence records (i.e. by
   periodically obtaining timestamps) for data objects submitted for

      - Collect and store additional verification data necessary to
   verify evidence records;

      - Provide archive packages containing archived data, evidence
   record or both;

      - Provide service according to a long-term archive policy;

    - The archive service MUST be able to provide evidence about the
   policies that have been used at any time.

      - Be able to provide archive packages even if the storage,
   software or processing technology changes during the lifetime of an
   archived data object;

      - Be able to provide an acknowledgement that a data object existed
   at a certain time, as an alternative, if user is not able to
   interpret the evidence record;

      - Operate per an archive policy, which at least determines quality
   of time-stamps and conditions for there renewal and etc;

      - If data objects are not stored by the Long-term-Archive-Service
   itself, there must exist mechanisms to make these data objects later
   available to the service if necessary in case of renewal of

   A long-term archive service must be able to work efficiently even for
   large amounts of archived data objects.  In order to limit expenses,
   costs and dependency on high performance, time-stamp services, the
   number of necessary time stamps MUST be minimized and a time stamp
   should include a large number of signatures and documents;

Wallace                    Expires July 2004                   [Page 8]

                Long-term archive service requirements   January 2004

   Necessity to access stored archived data object SHOULD be minimized.
   It SHOULD only be necessary access to the archived data objects only
   if the archived data objects are requested by users or if applied
   hash algorithms become insecure.

   A Long-term Archive Service may implement additional features, such
   as validation of data objects, if they are signed documents.

5.   Long-term Archive Service data structure requirements

   Standardization of data structures and processing procedures for an
   archive package will simplify the job of TAAs and enable verification
   by any user.

   The data structure for archive package should include the archived
   data objects and the evidence record.  Archived data objects may be
   included as part of the archive package so that it is possible to
   request only the evidence record.

   The data structure for the evidence record itself should have the
   following properties:

      - It MUST be possible to include all timestamps necessary to
   verify the existence of the archived data objects.

      - The timestamp data structure SHOULD be defined in such a way
   that it is possible to provide evidence for many archived data
   objects in an efficient way.

      - It SHOULD be possible to provide evidence for groups of archived
   data objects.  For example, it should be possible to archive a
   document file and a signature file together such that they get the
   same evidence record.

      - Where groups of data objects are submitted, non-repudiation
   proof MUST still be available for each archived data object

      - The deletion of archived data objects MUST NOT put the
   provability of other archived data at risk.

      - It SHOULD be possible to create timestamps without the need to
   access the archived data objects.  The access to the archived data
   SHOULD only be necessary if the security suitability of employed hash
   algorithm is menaced.

      - All hash algorithms applied to archived data over time SHOULD be
   identified in a single location to facilitate single pass

      - It SHOULD be possible to package all evidence along with the
   archived data objects in a single data item or to package evidence

Wallace                    Expires July 2004                   [Page 9]

                Long-term archive service requirements   January 2004

   and archived data objects in separate items.

      - It SHOULD be possible to provide evidence for encrypted archived
   data objects.  It SHOULD be possible to integrate information for the
   reconstruction of the archived data objects of the unencrypted data
   objects (key, algorithm, etc.).

      - It SHOULD be possible to integrate additional information for
   the verification of timestamps within the evidence record or the
   archived data object itself such as certificates and revocation
   information, the security suitability of applied algorithms and trust

6.   Long-term Archive Service Protocol requirements

   Standardization of a protocol for interactions with a Long-term
   Archive Service is desirable.  The protocol should have the following

      - The protocol MUST define interactions with a Long-term Archive
   Service including, at a minimum: submission of data or groups of
   data for preservation, retrieval of archive packages and deletion
   of archived data and associated evidence records.

      - The protocol MUST provide a response indicating successful
   submission or deletion of data.  The acknowledgement of successful
   submission SHOULD permit a submitter to verify that the correct data
   was received by the service for preservation, e.g. the
   acknowledgement could include an index, a signature or a timestamp
   obtained for the archived data object.

      - The protocol MUST response an index to retrieve the archive
   package.  It also should be possible to retrieve archive packages by
   using hash values of the archived data objects.

      - The protocol SHOULD support some basic Metadata (Mime-Type, key
   words,etc.), i.e. the client should be able to provide metadata
   along with the archived data to facilitate future search operations
   based on the metadata.

      - If a Long-term Archive Service does not support a client-
   requested long-term archive policy, the service MUST return an error.

      - A Long-term Archive Service MUST provide an indication of the
   long-term archive policy under which the service operates.

      - The protocol MUST prevent replay attacks.

      - The protocol SHOULD permit encryption of data before submission
   in such a way that there exists non-repudiation evidence for the
   unencrypted data.

Wallace                    Expires July 2004                  [Page 10]

                Long-term archive service requirements   January 2004

      - The protocol SHOULD provide means of associating submitted data
   objects with previously submitted data objects, i.e. to facilitate
   retrieval based on aggregation of objects over time.

      - The protocol SHOULD provide means for specifying a point in time
   at which an archived data object need no longer be preserved.  It
   also should be possible to extend the archiving period.

      - The protocol SHOULD provide the submission of evidence records
   previously generated by a different TAA.

      - The format for the acknowledgements MUST allow the
   identification of the archiving provider.

      - The format for the acknowledgements MUST allow (at least from
   the creating archiving provider) the identification of the
   participating client.

      - Responses must uniquely reference corresponding requests

      - It should be possible to sign requests and responses. It is
   recommended that in particular acknowledgements are signed.

      - Deletion must be authenticated.

      - The archive service MUST be able to provide evidence about the
   policies that have been used at any time

      - The protocol SHOULD be as simple to use as possible.

   Means to enable accountability, access control, confidentiality of
   communication between applications and TAA need additional
   precautions (like SSL) that are outside the scope of these

7.   Security Considerations

   Where non-standard formats are used or proprietary processing is
   employed, verification of signatures on or in archived data may
   require the availability of specific applications or tools.

   Certificate revocation could retroactively invalidate previously
   verified signatures.  Measures may be implemented to support such
   claims by an alleged signer, e.g. collection of revocation
   information after a grace period during which compromise can be
   reported or preservation of subsequent revocation information.

   Access control mechanisms associated with data stored by a TAA should
   consider the lifespan of the data object.  For example, the
   credentials of an entity that submitted data to an archive may not be
   available or valid when the data needs to be retrieved.

Wallace                    Expires July 2004                  [Page 11]

                Long-term archive service requirements   January 2004

   To achieve accountability, local means should be employed to ensure
   that all data is inserted in chronological order, e.g. by using
   write-once media.  Similarly, methods should be deployed to ensure
   that all deletions are detectable.

8.   Acknowledgements

   Thanks to Peter Sylvester for sharing information from the
   OpenEvidence project.

9.   Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2028]  Bradner, S. and R. Hovey, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3029]  Adams, C., Sylvester, P., Zolotarev, M. and R.
              Zuccherato, "Internet X.509 Public Key Infrastructure
              Data Validation and Certification Server Protocols", RFC
              3029, August 2001.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

Wallace                    Expires July 2004                  [Page 12]

                Long-term archive service requirements   January 2004

10.    Authors' Addresses

   Carl Wallace
   Orion Security Solutions
   Suite 300
   1489 Chain Bridge Road
   McLean, VA 22101
   E-Mail : cwallace@orionsec.com

   Ralf Brandner
   Otto-Hahn-Str. 3
   D-69190 Walldorf, Germany
   E-Mail: ralf.brandner@intercomponentware.com

   Ulrich Pordesch
   Fraunhofer Gesellschaft
   Institute Secure Telecooperation
   Dolivostrasse 15
   D-64293 Darmstadt, Germany
   E-Mail: ulrich.pordesch@sit.fraunhofer.de

Wallace                    Expires July 2004                  [Page 13]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/