LTANS service and protocol

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, thats 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, thats 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