1. LTANS service and protocol Carl Wallace (on behalf of Peter Sylvester) 6 Aug 2004, 60th IETF, San Diego

2. Current Authors Peter Sylvester – EdelWeb Carl Wallace – Orion Security Solutions Aleksey Jerman-Blazic – SETCCE

3. What – initial plan Services and protocol definitions for archiving Later: notarisation Goal: define a protocol that supports both long-term archive and notarization functions

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

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

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

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

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

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

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

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

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

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

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

15. Archive services Certain actions from TAP recombined into simple ones –Submission –Transfer –Policy configuration –… Need some work for combined data and ERS treatment

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

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

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