1 / 18

LTANS service and protocol

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

dbraxton
Télécharger la présentation

LTANS service and protocol

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

More Related