1 / 23

E-Archive Models, Protocols, and Data Structures for Long-Term Archiving

This presentation discusses the technical and organizational aspects of long-term archiving models, protocols, and data structures. It covers e-archive infrastructure and operation, e-archive data structures, security measures, ISO 17799 model, archival service operations, transport protocols, and abstract protocols. It also raises questions regarding execution of integrity service and communication of integrity information to clients.

nicolez
Download Presentation

E-Archive Models, Protocols, and Data Structures for Long-Term Archiving

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

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

  3. 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) P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  4. 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. P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

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

  6. 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? P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  7. 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' P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

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

  9. 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. P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  10. 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? P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  11. 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 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  12. 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. P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  13. 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)? P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  14. 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. P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  15. 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.) P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  16. 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 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  17. 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.) P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  18. 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 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  19. 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 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  20. 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?? P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  21. Structure Object Operation Metadata Metadata Single TimeStamp Security attributes Hash Tree - ERS Indexation data { Validation data Archive data structures Conservation attributes P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  22. 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? P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

  23. General information • Authors • Peter Sylvester, Edelweb • Aleksej Jerman Blazic, SETCCE • Date • March, 2004 P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE

More Related