Introduction The following slides were prepared as a

Introduction • The following slides were prepared as a result of analysis and discussion between authors on technical and organizational issues of long term archiving models, protocols and data structures • Two general domains are discussed: – E-archive infrastructure and operation – E-archive data structures • Enclosed points should serve as starting points formal representation of e-archiving based on technical and legal requirements IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Infrastructure model • Several layers (1/2 and 3/4 may be combined in some way) 1. End user controlled interface into a work flow application 2. End user parametrisable security and protocol layer 3. Company internal relay/broker 4. Company outgoing backend clients 5. Backend service notarisation front a service 6. Backend storage services. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Infrastructure protocols • Inter-layer protocol – Simple secure communication between 1/2 and 3/4, trust MAY be based on communication, not on signatures of responses, minimal trust base. – 4/5 backend is third party delivering attestations (strawman DVCS/RFC 3029 like) – 5/6 internal API or simple protocol (functions need to be defined) IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Security • Security model of application (cf BS 7799/ISO 17799) – Both for client and service • Application/workflow has whatever it has for audit: Control Communication with a relay providing attestations of notarisations including archival as one security measure. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

ISO 17799 model Two security measures: -archive service for the end client -Time stamping for the service itself Control Service User Application Context Arch. /Notary Service Archive service IETF - LTANS, March 2004 Sec. Mes. timestamp Control & Audit P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Security model • Security model of archival services – Service is provided by operation 4/5 – security measure is an integrity ensuring mechanism – at least using time stamps. – Questions: • What to time stamp: activity log and/or archived data. • Auditing techniques: may randomly validate attestations? IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Service operation • Archival service operation classes (4/5) – submit data and obtain attestation(s) – validate authenticity of an attestation with or without returning the data. result may be 'has been deleted before. . . according to request. . . verification may be simply 'signature validation’ or 'checking attestation/data' IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Service operation cont. – transfer/deletion operation produces an attestation is kept as "integrity anchor" to replace deleted/transferred journal and archive entries. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Service operation cont. • Transport – similar to XKMS (forget about encodings at the moment) – Asynchronous paradigm or at least multiple responses. – Multiple mappings possible in the future – Separation of secure transport and syntax/semantics of an 'attestation" as much as possible. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Abstract protocol • Implemented by archive/notary service (central box on earlier diagram) – Three types of messages • Submission requests • Management requests • Responses – All message types • identify sender and recipient – Should all message types may provide replay protection or idempotence of operation? IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Abstract protocol (continued) • Submission requests are used to: – Convey groups of data objects and related information for archiving • Mechanisms for data submission will include – direct inclusion of data – specification of a URI where data can be found – specification of an index for data (i. e. for cases where data is already held by TAA) • For each data object – – identify requested archive policy specify archive period specify metadata provide indication of type of information that should be returned – Transfer data and/or records from one provider to another IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Abstract protocol (continued) • Management requests are used to: – Retrieve archived data, metadata, evidence, etc. – Initiate searches – Initiate transfer archive data and/or evidence – Add/replace metadata, period, policy • Responses are used to: – convey status information – convey attestations, archived data, metadata, document ID, evidence, etc. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Issues • Questions: – How/when does archiver execute its integrity service? – To what degree the integrity info can be communicated? – To the clients (goal, get rid of signatures and keys)? IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Answers • Possible solution: – Client first asks for archival and gets a signed response (triggered by notification or after some time): – Client has obtained a globally published hash and requests validation of the previous operation, Result is an attestation containing a hash chain. IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Data structures • Security aspect – Data structures that are necessary to prove the existence and integrity of data archived for an unlimited period of time • Interaction aspect – Formal data needed to evidence interactions with an archive (object successful submission, archived object validation result, etc. ) IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Data structures cont. • Validation aspect – Data structures to evidence the existence and validity of applied security attributes (e. g. electronic signature) over object(s) over archival time • Operational aspect – Data structures to index and manage archived objects (out of the scope of LTANS? ) in a formal way IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Security • ERS – Structures for conservation purposes based on time relevant techniques – Data formats and processing procedures for Time-Stamps in order to be able to verify and communicate archived data (and metadata) preserving evidence – Related or unrelated? to used conservation techniques (e. g. time stamp, hash linking, etc. ) IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Interaction • Formal attestation – Object submission – Object existence – Object deletion – Validity of archived object (revision) • For attestation data existence and integrity also need to be provided for the archival period IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Validation • Validation of security attributes – Attestation of validity in time: Proof of the existence and integrity of security attributes – Self driven attestation Self reference collection (on the basis of RFC 3126), like OCSP response, CRL download, etc. ) – manage validation completely by end-user (client? ) – Authority driven attestation Validity proof (formal attestation) by authority (based on DVCS interaction or also OCSP is somehow considered as an authority driven approach) – put the complete focus of a trust on thrid party authority IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Operation • Object metadata – Archiving related metadata Creation place and date, author, etc. – a must have in legal constrains – Managing related metadata Out of the scope… (what is the correlation with METSlike standards) – Presentation related data Format transformation (obsolete format replacement by encapsulation procedures – transformation on the fly) – formal and certified procedures – out of the scope or not? ? IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Structure Object Operation Metadata Archive data structures Security attributes Single Time Stamp Hash Tree - ERS { Indexation data Validation data IETF - LTANS, March 2004 Conservation attributes P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

Questions • To what extent data structures have to be defined? • How does archive receive “raw” object (e. g. object without metadata? Is metadata (workflow, etc. ) part of archival process? • How is a transparency achieved through technology (e. g. how are data structures transferred through different underlying technology)? • Does TAP (or other archiving related protocol) deal with procedures attestation? Where attestations kept (securely)? Is this a part of the (meta)data structure? IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

General information • Authors – Peter Sylvester, Edelweb – Aleksej Jerman Blazic, SETCCE • Date – March, 2004 IETF - LTANS, March 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE