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

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

Long-term Archive And Notary                                  C. Wallace
Services (LTANS)                                Orion Security Solutions
Internet-Draft                                               U. Pordesch
Expires: March 22, 2005                          Fraunhofer Gesellschaft
                                                             R. Brandner
                                                   InterComponentWare AG
                                                      September 21, 2004


                 Long term archive service requirements
                      draft-ietf-ltans-reqs-02.txt

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted 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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 22, 2005.

Copyright Notice

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

Abstract

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






Wallace, et al.          Expires March 22, 2005                 [Page 1]

Internet-Draft    Long term archive service requirements  September 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  General Principles . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Technical Requirements . . . . . . . . . . . . . . . . . . . .  7
     4.1   Enable submission, retrieval and deletion of archived
           data objects . . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1   Functional Requirements  . . . . . . . . . . . . . . .  7
       4.1.2   Rationale  . . . . . . . . . . . . . . . . . . . . . .  8
     4.2   Provide evidence records . . . . . . . . . . . . . . . . .  8
       4.2.1   Functional Requirements  . . . . . . . . . . . . . . .  8
       4.2.2   Rationale  . . . . . . . . . . . . . . . . . . . . . .  8
     4.3   Support Demonstration of Data Integrity  . . . . . . . . .  8
       4.3.1   Functional Requirements  . . . . . . . . . . . . . . .  8
       4.3.2   Rationale  . . . . . . . . . . . . . . . . . . . . . .  8
     4.4   Operate per a long-term archive policy . . . . . . . . . .  8
       4.4.1   Functional Requirements  . . . . . . . . . . . . . . .  9
       4.4.2   Rationale  . . . . . . . . . . . . . . . . . . . . . .  9
     4.5   Data confidentiality . . . . . . . . . . . . . . . . . . .  9
       4.5.1   Functional Requirements  . . . . . . . . . . . . . . .  9
       4.5.2   Rationale  . . . . . . . . . . . . . . . . . . . . . .  9
     4.6   Data and evidence transferability  . . . . . . . . . . . .  9
       4.6.1   Functional Requirements  . . . . . . . . . . . . . . . 10
       4.6.2   Rationale  . . . . . . . . . . . . . . . . . . . . . . 10
     4.7   Supporting Groups of Data  . . . . . . . . . . . . . . . . 10
       4.7.1   Functional Requirements  . . . . . . . . . . . . . . . 10
       4.7.2   Rationale  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Operational Considerations . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   A.  Application scenarios  . . . . . . . . . . . . . . . . . . . . 15
     A.1   Archive service supporting long-term non-repudiation . . . 15
     A.2   Pure long-term non-repudiation service . . . . . . . . . . 15
     A.3   Long-term Archive Service as part of an internal
           network  . . . . . . . . . . . . . . . . . . . . . . . . . 15
     A.4   Long-term Archive External Service . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16











Wallace, et al.          Expires March 22, 2005                 [Page 2]

Internet-Draft    Long term archive service requirements  September 2004


1.  Introduction

   Digital data durability is undermined by continual progress and
   change on a number of fronts.  The useful lifetime of data may exceed
   the life span of formats and mechanisms used to store the data.  The
   lifetime of digitally signed data may exceed the validity periods of
   public-key certificates used to verify signatures or the
   cryptanalysis period of the cryptographic algorithms used to generate
   the signatures.  Technical and operational means are required to
   mitigate these issues.  A solution must address issues such as
   storage media lifetime, disaster planning, advances in cryptanalysis
   or computational capabilities, changes in software technology and
   legal issues.

   A long-term archive service aids in the preservation of data over
   long periods of time through a regimen of techinical and procedural
   mechanisms designed to support claims regarding a data object.  For
   example, it might periodically perform activities to preserve data
   integrity and the non-reputability of data existence as well as
   ensuring the availability of data.  Examples of periodic activities
   include refreshing timestamps or transferring data to a new storage
   medium.

   A long-term archive service may be used to support validation of the
   existence of documents, or assertions of agreements, originally
   asserted with digital signatures.  Validation may occur at times in
   the future well beyond the validity period of the private key
   originally used to generate the signature, or even the validity of
   the algorithms available for digital signatures, message digesting or
   data encryption.

   A long-term archive service may be located within an enterprise
   network, communicating with local storage mechanisms and other
   applications, or a long-term archive service may be implemented as an
   external service accessible via an internet.  A long-term archive
   service may use functionality, e.g.  time stamping, provided by
   independent service providers.

   A primary goal of a long-term archive service is to support the
   credible assertion of something that is currently asserted at points
   well into the future.  A long-term archive service may support a
   range of applications, including: wills, land records, medical data,
   criminal case files, personnel files, contracts.  A long-term archive
   service may be used by any type of entity, e.g.  organizations,
   citizens, notaries.  Examples of long-term archive service usage by
   submitters include:





Wallace, et al.          Expires March 22, 2005                 [Page 3]

Internet-Draft    Long term archive service requirements  September 2004


      - A company stores contracts using a third party service
      - A hospital stores medical data using an internal service
      - An individual wants to generate evidence of data possession at a
      particular point in time, e.g.  for intellectual property purposes
      or endorsement of a contract
      - A law enforcement officer wants to store criminal data such that
      integrity of the data can be demonstrated years later


   For each of the above examples, there is a corresponding example
   involving retrievers, e.g.  a company retrieves a contract in the
   case of a dispute or a law enforcement officer prepares information
   for a criminal trial.

   This document addresses the technical requirements for a long-term
   archive service.  The requirements for long-term notarization
   services will be covered by a separate draft.


































Wallace, et al.          Expires March 22, 2005                 [Page 4]

Internet-Draft    Long term archive service requirements  September 2004


2.  Terminology


      Arbitrator: Principal for whom the validity of archived data
      characteristics, e.g., origin, integrity or time of existence,
      must be demonstrated.

      Archivation period: The period during which an archived data
      object is preserved by a long-term archive service.

      Archived data object: Data unit to be preserved by a long-term
      archive service.

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

      Evidence: Information that may be used to demonstrate the validity
      an archived data object or related attestations.

      Evidence record: Collection of evidence compiled for one or more
      archived data objects.  An evidence record may include
      acknowledgements from a LTA, timestamps and verification data,
      such as public-key certificates, revocation information, trust
      anchors, policy details and role information.

      Long-term archive policy: A named set of rules that define
      operational characteristics of a long-term archive service.

      Long-term archive service (LTA): A service that is responsible for
      preserving data for long periods.

      Originator: Principal who produces, and possibly signs, an
      archived data object.The Originator does not necessarily have any
      relationship with a long-term archive service or any awareness of
      an evidence record associated with the archived data object.

      Retriever: Principal who retrieves an archived data objects and/or
      evidence record from a long-term archive service.

      Submitter: Principal who submits data objects for archiving.

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

      Time Stamping Authority (TSA): A service that generates
      timestamps.



Wallace, et al.          Expires March 22, 2005                 [Page 5]

Internet-Draft    Long term archive service requirements  September 2004


3.  General Principles

   A long-term archive service may accept any type of data for
   preservation, including digitally signed data, encrypted data, time
   stamped data, data that has not been the subject of any cryptographic
   processing, textual data or images.

   A long-term archive service may preserve archived data objects as
   opaque collections of bytes with the primary aim being demonstration
   of data integrity.

   A long-term archive service does not operate upon evidence related to
   the content of archived data objects.  Content-focused operations,
   including data format migration or translation, may be performed by a
   notary or notarization service.

   A long-term archive service preserves archived data objects over
   arbitrarily long periods of time.

   A long-term archive service provides material needed to demonstrate
   the existence and integrity of data objects.






























Wallace, et al.          Expires March 22, 2005                 [Page 6]

Internet-Draft    Long term archive service requirements  September 2004


4.  Technical Requirements

   This section describes requirements for a long-term archive system.

4.1  Enable submission, retrieval and deletion of archived data objects

4.1.1  Functional Requirements

   A long-term archive service must permit clients to perform the
   following basic operations:

      - submit data and receive an acknowledgement or proof of deposit
      - retrieve archived data objects,
      - delete archived data objects/terminate archivation period for an
      archived data object.

   Submitters must be able to specify an archivation period.  It should
   be possible to extend the archiving period after the initial
   submission.  Submitters should be able to specify metadata that, for
   example, can be used to enable retrievers to render the data
   correctly.

   Following submission, the service must provide a value that can be
   used to retrieve the archived data and/or associated evidence.  It
   may be possible to retrieve archive packages by using a hash value of
   an archived data object.

   Deletion requests must be authorized and an authorization policy must
   be defined and observed by the long-term archive service (as part of
   an archive policy).  In some cases, deletion may not involve physical
   deletion and instead may simply be an early termination of the
   archivation period.

   It must be possible to authenticate requests and responses, e.g.  to
   enable LTAs to render an authorization decision.  This may be
   accomplished using transport security mechanisms.

   The format for the acknowledgements must allow the identification of
   the archiving provider.

   The format for the acknowledgements must allow the identification of
   the participating client.

   The LTA must provide an acknowledgement, or proof of deposit, that
   permits the submitter to confirm the correct data was accepted by the
   LTA.  This proof need not be provided immediately.





Wallace, et al.          Expires March 22, 2005                 [Page 7]

Internet-Draft    Long term archive service requirements  September 2004


4.1.2  Rationale

   Submission, retrieval and deletion of archived data objects are
   necessary basic functions of a long-term archive service.

4.2  Provide evidence records

4.2.1  Functional Requirements

   A long-term archive service must be capable of providing evidence
   records to support the long-term non-repudiation of data, e.g.  in
   the case of legal disputes.

   It must be possible to submit data along with previously generated
   evidence, i.e.  to support transfer of data from one archive to
   another.  Submitters must be able to specify metadata that, for
   example, can be used to provide enable retrievers to render the data
   correctly.

4.2.2  Rationale

   Supporting non-repudiation of data existence and origin is a primary
   purpose of a long-term archive service.  Evidence may be generated by
   or otherwise obtained by the service providing them to a retriever.
   A long-term archive service need not be capable of providing all
   evidence necessary to produce a non-repudiation proof.  In
   particular, trust anchors and algorithm security policies have to be
   provided by other services.

4.3  Support Demonstration of Data Integrity

4.3.1  Functional Requirements

   A long-term archive service must be capable of producing evidence
   that can be used to demonstrate the integrity of data for which it is
   responsible from the time it received the data until the expiration
   of the archivation period of the data.

4.3.2  Rationale

   Demonstration that data has not been altered while in the care of a
   long-term archive service is a first step towards supporting
   non-repudiation of data.  Content-focused operations will be the
   function of a notarization service.

4.4  Operate per a long-term archive policy





Wallace, et al.          Expires March 22, 2005                 [Page 8]

Internet-Draft    Long term archive service requirements  September 2004


4.4.1  Functional Requirements

   A long-term archive service must operate per a long-term archive
   service policy that defines characteristics of the implementation of
   the long-term archive service.  The policy may define characteristics
   such as the quality of timestamps obtained or generated by the
   long-term archive service or triggers for preservation activities,
   e.g.  timestamp refresh or data format migration.

   A long-term archive service must be able to provide information
   identifying the policies in use at any point in time.  Submitters
   must be able to indicate the archive policy under which the submitted
   data should be handled.  The service must provide an indication of
   the archive policy observed by the service.  If a long-term archive
   service does not support a client-requested policy, it must return an
   error indication.

4.4.2  Rationale

   Similar to a certificate policy, a long-term archive policy provides
   a shorthand means of technically expressing a set of rules that
   govern operation of a long-term archive service.

4.5  Data confidentiality

4.5.1  Functional Requirements

   A long-term archive service must provide means to ensure
   confidentiality of archived data objects, including confidentiality
   between the submitter and the long term archive service.

   Standard encryption algorithms and formats, e.g.  AES and CMS, should
   be supported.

   The concept should be open to add other methods for confidentiality,
   like sharing secrets between different archive providers.

   Encryption or other methods must not pose a risk to evidence.

4.5.2  Rationale

   Individuals may wish to use the services of a commercial long-term
   service without disclosing data to the commercial service.

4.6  Data and evidence transferability






Wallace, et al.          Expires March 22, 2005                 [Page 9]

Internet-Draft    Long term archive service requirements  September 2004


4.6.1  Functional Requirements

   A long-term archive service must support the transfer of archived
   data objects, evidence and evidence records from one service to
   another.

4.6.2  Rationale

   Before the end of an archived data object's archivation period, a
   long-term archive service may cease operation.  In such cases, it
   must be possible for the archived data object (and any associated
   evidence) to be transferred to another service that will continue
   preservation of the data until the end of the archivation period.

4.7  Supporting Groups of Data

4.7.1  Functional Requirements

   The service should support groups of data objects.

   Submitters should be able to indicate which data objects belong
   together, i.e.  comprise a group.  Retrievers should be able to
   retrieve all members of a group of data objects.

   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 are covered by the
   same evidence record.

   Where an LTA operates upon groups of data objects, non-repudiation
   proof must still be available for each archived data object
   separately.

4.7.2  Rationale

   In many cases data objects belong together.  Examples include:

   - a document file and an associated signature file, which are two
   separate objects

   - TIF-files representing pages of a document

   - a document file and an evidence file (possibly generated by another
   LTA or notary service)

   In these cases, it is to the best advantage to handle these data
   objects as a group.




Wallace, et al.          Expires March 22, 2005                [Page 10]

Internet-Draft    Long term archive service requirements  September 2004


5.  Operational Considerations

   A long-term archive service must be able to work efficiently even for
   large amounts of archived data objects.  In order to limit expenses
   and to achieve high performance, it may be desirable to minimize the
   use of trusted third parties, e.g.  LTA operations should be designed
   to limit the number of timestamps required to provide the desired
   level of service.

   Necessity to access archived data objects should be minimized.  It
   may only be necessary access to the archived data objects if the
   archived data objects are requested by users or if hash algorithms
   used for indexing or evidence record generation become insecure.






































Wallace, et al.          Expires March 22, 2005                [Page 11]

Internet-Draft    Long term archive service requirements  September 2004


6.  Security Considerations

   Data is the principal asset protected by a long-term archive service.
   The principle threat addressed by a long-term archive service is
   undetected loss of data integrity.

   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.

   When selecting access control mechanisms associated with data stored
   by a LTA, the lifespan of the archived data object should be
   considered.  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.

   During lifespan of an archived data object, formats may cease to be
   supported.  Software components to process data, including content or
   signatures, may no longer available.  This could be a problem
   particularly if non-standard formats are used or proprietary
   processing is employed.  The submitter should take care to avoid this
   potential problem.  For example, the submitter could periodically
   retrieve data, convert the data and re-submit it in new format.  Of
   course additional mechanisms, applications or tools are needed in
   order to conserve evidence value.  Other specifications of LTANS, in
   particular to notary services will address these problems.

   Some applications may require processing of a chain of archive
   policies present in an evidence record, e.g.  to ensure that
   compatible policies were used throughout the lifetime of an archived
   data object.


















Wallace, et al.          Expires March 22, 2005                [Page 12]

Internet-Draft    Long term archive service requirements  September 2004


7.  Acknowledgements

   Thanks to members of the LTANS mailing list for review of earlier
   drafts and many suggestions.

8  References

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

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

   [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, February
              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.


Authors' Addresses

   Carl Wallace
   Orion Security Solutions
   Suite 300
   1489 Chain Bridge Road
   McLean, VA  22101

   Fax:   +1(703)917-0260
   EMail: cwallace@orionsec.com


   Ulrich Pordesch
   Fraunhofer Gesellschaft
   Dolivostrasse 15
   Darmstadt, Germany  D-64293

   EMail: ulrich.pordesch@zv.fraunhofer.de






Wallace, et al.          Expires March 22, 2005                [Page 13]

Internet-Draft    Long term archive service requirements  September 2004


   Ralf Brandner
   InterComponentWare AG
   Otto-Hahn-Strabe 3
   Walldorf, Germany  69190

   EMail: ralf.brandner@intercomponentware.com













































Wallace, et al.          Expires March 22, 2005                [Page 14]

Internet-Draft    Long term archive service requirements  September 2004


Appendix A.  Application scenarios

   Below are several example application scenarios demonstrating one or
   more of the basic service features mentioned above.

A.1  Archive service supporting long-term non-repudiation

   A long-term archive service may store data objects, like signed or
   unsigned documents, for authenticated users.  It may generate time
   stamps for these data objects and obtain verification data during the
   archivation period or until a deletion request is received from an
   authorized entity.

A.2  Pure long-term non-repudiation service

   A long-term archive service may only guarantee non-repudiation of
   existence of data by periodically generating time stamps and
   obtaining verification data.  It stores data objects (e.g.  documents
   and signatures) locally only for the purpose of non-repudiation and
   does not function as a document archive for users.  It does not
   support retrieval and deletion of data objects.

A.3  Long-term Archive Service as part of an internal network

   A long-term archive service may be part of an enterprise network.
   The network provider and archive provider may be the same
   institution.  In this case, the provider will use an external TSA, to
   generate non-repudiation evidence from a third party.  An internally
   generated acknowledgement would be worthless.

A.4  Long-term Archive External Service

   A long-term archive service may be provided over the internet for
   enterprises or consumers.  In this case, archiving and providing
   evidence (via time-stamps or other means) may be adduced by one
   organisation and its own technical infrastructure without using
   external services.














Wallace, et al.          Expires March 22, 2005                [Page 15]

Internet-Draft    Long term archive service requirements  September 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Wallace, et al.          Expires March 22, 2005                [Page 16]

Internet-Draft    Long term archive service requirements  September 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Wallace, et al.          Expires March 22, 2005                [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/