LTANS service and protocol

Carl Wallace

(on behalf of Peter Sylvester)

6 Aug 2004, 60th IETF, San Diego

Current Authors

• Peter Sylvester – EdelWeb

• Carl Wallace – Orion Security Solutions

• Aleksey Jerman-Blazic – SETCCE

What – initial plan

• Services and protocol definitions for archiving

• Later: notarisation

• Goal: define a protocol that supports both long-term archive and notarization functions

Achievements and current status

• Review of different inputs, e.g. TAP, DVCS, ERS, …

• Fold out common elements

• Getting a common understanding

• Remove dependencies related to encoding and lower layers

• An initial text exists but is not complete.

Approach

• Request – response type protocol• Protocol must be asynchronous by nature

– Engagement of archive provider cannot be immediate, only after backup etc…

– Data to be restored may not be available on line.• Protocol can use online transports like HTTP

– At least two stages: submission, confirmation• Protocol used to transfer data, transfer evidence and

manage data preservation activities– Evidence verification details are in ERS; need to proceed carefully

to make sure nothing falls between the cracks (especially if alternative evidence formats are permitted)

• All of this is similar to SAML

Request/response formats

• Payload data and/or evidence data

• Generic data (contractual, identification, dates, rules, some meta info)

• Optional security envelopes

• Optional secure transport

• Inspired by DVCS and folding from TAP

Requests

• Indicate that they are requests

• Generic description of transaction– Similar to RequestInformation of DVCS

• Participants, nature of requested service, policy, dates, …

• Data (will be transformed into hash)– Some metadata, remain clear in response

• Descriptions, filename, mimetype, locations

Data

• Data format needs to be known– An HTML doc seen as HTML vs. text– Cf. MIME encapsulation in S/MIME

• Associate an HTTP response to archive response (comparison with a hash).– Need to bind mime type etc.– Hashing the raw data + header info in clear.

• Raw data may have structure and metainfo 

Response structure

• Global error

• Attestation concerning the transaction– Copy of generic information and metadata– Hash of data– Identification: date, serial number, service ID– Additional information according to transaction

type.

Transactions

• Requests + responses.– Submission request + (opt initial) response– (opt) Confirmation request for response– Confirmation response.– Requests for « evidence » (ERS)

• Additional responses for archive transformations.– Requests/responses linked together (not just by hashes)

• Relaying, proxies need some more work• n/k splitting needs some thoughts

Identifications

• Need a chance to survive for long term• Participating entities

– GeneralName seems good enough as container

– Authentication and Authorisation is out of scope, we just carry identifiers, and security envelopes

• Data – redundancy principle– Hash + serial number + service id + some metainfo

Document structure

• Generic framework

• Payloads for archive service

• Notary service can reuse generic framework

• Proposition: Separate smaller documents– Framework– Archive, notary services on top– Bindings to lower layers

Framework

• Pretty advanced but …– Need some input from requirments

• Type of actors

• Type of attestations, confirmations, proofs

– Some concrete use cases/examples would be useful.

• Still too much ASN.1, transformation to abstract indications.

Bindings

• Transport + security• Encoding + security• Payloads• CMS, TLS, ASN1, ContentInfo, MIME ..• Framework should allow XML based solutions

(e.g. XER, that’s simple) but also XML-DSIG.• Open for BEEP, SOAP, SASL, etc.… • Transformation of formats can be done by a

specialized archive service (XML-DSIG)

Archive services

• Certain actions from TAP recombined into simple ones– Submission– Transfer– Policy configuration– …

• Need some work for combined data and ERS treatment

Miscellaneous

• Common understanding of problem grows among authors and others, that’s good

• Some new contributors• Other related IETF work

– E.g. structured ContentInfo draft from Russ Housley

– Content-type URI from Eastlake– Atompub (metadata)

A Few Issues/Questions

• Multiple item submission– Should the protocol permit submission of

multiple items in a single request (to align with ERS capabilities)?

• Could get fairly complicated

A Few Issues/Questions (continued)

• Transaction set– Submission and retrieval/transfer/deletion of data and

evidence– Management of metadata?

• To what extent should generic data associated with a payload be managed via the protocol?

• Manage small number of attributes related to service operation, e.g. retention period

• Managing authorization over long term is a challenge– Searching?

• Could be factored into a different protocol with the data identifier being the link between the two