IETF - LTANS, March 2004P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE 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 for formal representation of e-archiving based on technical and legal requirements

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

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

IETF - LTANS, March 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 2004P. 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 RFC3126), 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 2004P. 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 METS- like 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 2004P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE Structure Object Metadata Security attributes Indexation data Validation data Conservation attributes Hash Tree - ERS Operation Metadata { Archive data structures Single Time Stamp

IETF - LTANS, March 2004P. 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 are attestations kept (securely)? Is this a part of the (meta)data structure?

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