Long-term Archive Service Requirements

1. Long-term Archive Service Requirements November 9, 2004

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

3. Issues • Mechanism neutrality • Work flow • Policy representation and enforcement • Miscellaneous

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

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

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

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

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

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

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

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