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- Drafts. 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 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 preservation; - 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 time-stamps. 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 separately. - 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 verification. - 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 anchors. 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 properties: - 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 requirements. 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 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, 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]