1. Long-term Archive Service Requirements draft-ietf-ltans-reqs-00.txt

2. November 200358 th IETF - Minneapolis2 Current Draft Completed too late to submit to IETF in advance of the WG session –Posted to LTANS web site and link sent to the mailing list –Has been (briefly) discussed on mailing list Identifies the functional and technical requirements for a long-term archive service Authors: Carl Wallace, Ralf Brandner and Ulrich Pordesch

3. November 200358 th IETF - Minneapolis3 Topics Scenarios –How/when/why will service be used? Terminology Functional Requirements –What should service do? Data Structure Requirements –How will evidence be generated and represented? Protocol Requirements –How will interaction with service be performed?

4. November 200358 th IETF - Minneapolis4 Scenarios Long-term archive problems and tasks –Availability and integrity of data for long periods of time Birth certificates, tax documents, wills, etc. –Demonstration of proof of existence and integrity for court Prove existence of a document, prove integrity of criminal evidence, etc. –Preservation of evidence for signed or timestamped data Store material to facilitate future verification

5. November 200358 th IETF - Minneapolis5 Terminology Trusted Archiving: A process that includes storing data objects for long periods of time while preserving data integrity via periodic generation of timestamps and collection of evidence. Archived data object: Data unit that is archived and preserved by a Long-term Archive Service. Evidence: Information that may be used to resolve a dispute about various aspects of authenticity of archived data objects.

6. November 200358 th IETF - Minneapolis6 Terminology (continued) Evidence record: Collection of evidence compiled for one or more archived data objects over time. An evidence record may include timestamps and additional verification data such as certificates, revocation information, trust anchors, policy details, role information, etc. Archive package : Collection of information including archived data objects and the associated evidence record.

7. November 200358 th IETF - Minneapolis7 Functional Requirements - 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, e.g. certificates, CRLs, trust anchors; - Provide archive packages containing archived data and/or evidence - Operate according to a long-term archive policy that, minimally, determines quality of time-stamps, conditions for renewal, etc; - 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; -Necessity to stored access archived data should be minimized.

8. November 200358 th IETF - Minneapolis8 Functional Requirements (from mailing list discussion) -An archive service must not be able to insert data in a non- chronological way -An archive service must not be able to delete data from an archive without detection -An archive service should be able to provide service in a staged way, i.e. provide initial acknowledgements followed by final ones (client may obtain final acknowledgements by an asynchronous method, e.g. email) -It should be possible to use a broker-style service provider to relay requests to back-end service providers

9. November 200358 th IETF - Minneapolis9 Data Structure Requirements - It MUST be possible to include all timestamps necessary to verify the existence of the archived data objects. - It SHOULD be possible to include 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. - 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. For example, it should be possible to archive a document file and a signature file together such that they get the same evidence record. - 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 not sufficient.

10. November 200358 th IETF - Minneapolis10 Data Structure Requirements (continued) - Where groups of data objects are submitted, non-repudiation proof MUST still be available for each archived data object separately. - It SHOULD be possible to package all evidence along with the archived data objects in a single data item or to package evidence and archived data objects in separate items. - It SHOULD be possible to provide evidence for encrypted archived data objects and it SHOULD be possible to include information for the recovery of the archived data objects in unencrypted form (key, algorithm, etc.). - All hash algorithms applied to archived data over time SHOULD be identified in a single location to facilitate single pass verification. - The deletion of archived data objects MUST NOT put the provability of other archived data at risk.

11. November 200358 th IETF - Minneapolis11 Data Structure Requirements (from mailing list discussion) -Evidence structure must include a means of identifying the archive service. -Evidence structure must include a means of identifying the participating client. -It should be possible to use a variety of timestamp formats.

12. November 200358 th IETF - Minneapolis12 Protocol Requirements - 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 provide a response containing information, e.g. an index, to facilitate retrieval of the the archive package. It also should be possible to retrieve archive packages by using hash values of the archived data objects. - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an error.

13. November 200358 th IETF - Minneapolis13 Protocol Requirements (continued) - 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 for the submission of evidence records previously generated by a different TAA. - The protocol SHOULD be as simple to use as possible. - The protocol SHOULD permit encryption of data before submission in such a way that there exists non-repudiation evidence for the unencrypted data. - The protocol MUST prevent replay attacks. - The protocol MUST include a means of indicating the long-term archive policy under which the service operates.

14. November 200358 th IETF - Minneapolis14 Protocol Requirements (from mailing list discussion) -A client (or other relying party) MUST be able to prove that a particular acknowledgement corresponds to a request made by the client, e.g. via a global identifier. -It MUST be possible to include metadata concerning the archived data, e.g. MIME type, file name, a short description, etc. -Protocol SHOULD include a “confirm existence” transaction, which may include a reference to another provider in the response. -Format for acknowledgements MUST include a means of identifying the archive service. -Format for acknowledgements MUST include a means of identifying the participating client.

15. November 200358 th IETF - Minneapolis15 Next Steps Incorporate additional requirements and respond to comments General clean-up and editing Add sections addressing operational and/or legal requirements? Submit updated version of current draft to IETF as -00 draft by the end of November