IETF - LTANS, March 2004P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE Introduction The following...

IETF - LTANS, March 2004

P. 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



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.



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)



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.



ISO 17799 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



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?



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'



Service operation cont.

– transfer/deletion operationproduces an attestation

attestation is kept as "integrity anchor" to replace deleted/transferred journal and archive entries.



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.



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?



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



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.



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)?



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.



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.)



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



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.)



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



Validation

• Validation of security attributes– Attestation of validity in time:

Proof of the existence and integrity of security attributes

– Self driven attestationSelf reference collection (on the basis of RFC3126), like

OCSP response, CRL download, etc.) – manage validation completely by end-user (client?)

– Authority driven attestationValidity 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



Operation

• Object metadata– Archiving related metadata

Creation place and date, author, etc. – a must have in legal constrains

– Managing related metadataOut of the scope… (what is the correlation with METS-

like standards)

– Presentation related dataFormat transformation (obsolete format replacement by

encapsulation procedures – transformation on the fly) – formal and certified procedures – out of the scope or not??



Structure

Object

Metadata

Securityattributes

Indexation data

Validation data

Conservationattributes

Hash Tree - ERS

OperationMetadata

{

Arc

hiv

e d

ata

stru

ctu

res

Single Time Stamp



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?



General information

• Authors– Peter Sylvester, Edelweb– Aleksej Jerman Blazic, SETCCE

• Date– March, 2004

IETF - LTANS, March 2004P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE Introduction The following...

Documents

Transcript of IETF - LTANS, March 2004P. Sylvester, Edelweb & A. Jerman Blazic, SETCCE Introduction The following...