Long-term Archive Service Requirements November 9, 2004

Current Status Last call for -02 generated much discussion Version -03 posted in October At least one more version will be released before Minneapolis meeting in March

Issues Mechanism neutrality Work flow Policy representation and enforcement Miscellaneous

Issue: Mechanism neutrality The current requirements document is (more or less) mechanism neutral –Should it remain so? –Several possible mechanisms have been discussed: refreshed signature-based timestamps, refreshed linking hash-based timestamps, multi-party control (e.g. n of m) Most list discussion focuses on cryptographic or PKI- based solutions to problem –Where should details related to these mechanisms be captured? –Is it likely that non-cryptographic mechanisms will be used for long-term signature preservation (and if so, are they the concern of this WG)?

Possible way forward: Mechanism neutrality Keep document mechanism neutral –Minimally to accommodate signature and linking hash based solutions Capture mechanism specific details in specification documents (e.g. ERS) –Focus mechanism-centric discussion towards protocol specifications

Issue: Work flow Are multi-stage acknowledgements required? –For example, initial acknowledgement indicating receipt of data by LTA, subsequent acknowledgement indicating verification of data (possibly after a grace period to catch revocation declaration) and final acknowledgement indicating storage and initiation of preservation activities. Seems like yes –In which case, refreshed timestamp-focused evidence records miss the mark –“Property bag” may be appropriated (of which one instance is a refreshed timestamp) Data certification evidence is another instance

Possible way forward: Work flow Add a requirement for multi-stage (or independent) acknowledgements –This also addresses retroactive revocation requirement Review ERS structure for support for this requirement Consider relationships between acknowledgements or attributes in LTA signature structure and whether there is a need for preserved and unpreserved properties –Unpreserved conveys information that changes over time (e.g. classification code) –Preserved conveys (signed?) information that requires additional safeguards (e.g. subject to future refresh operations)

Issue: Archive policy Policy discussions have been most detailed of recent list discussions –Highly mechanism specific –Address cryptographic policy aspects independent of mechanism? Policy requirements needed to drive specification of protocol interface –If policy is applied on transaction basis How detailed does policy processing need to be at validation time (i.e. policy chain processing)? –Do we need more than a “named set of rules”? –Does policy matter to relying party at verification time? –Should LTA be able to supply policy details for any time T during its lifetime?

Possible way forward: Archive policy Prepare Internet Draft focusing on components of archive policy –Framework (a la CP/CPS framework)? –Any volunteers? Identify components of archive policy –Client components and server components –Policy expressed on a per-document basis (as part of archive protocol?) and default policy

Miscellaneous Need to delineate operational modes, e.g. active vs. passive? Attestations related to placement at storage server? Data origin necessary?

Summary Aim for last call before Minneapolis Focus group discussion on specifications –ERS –Prepare draft WebDAV binding –Complete draft DVCS-like protocol