draft-ietf-ltans-reqs-02.txt: Archive policy-related comments

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

A number of comments on the -02 requirements draft relate to archive policy.
This thread collects the policy-related questions/comments and offers an
initial set of archive policy components and a few responses.

1) What are the primary components of an Archive Policy?  

	- Based on the comments, a few candidate archive policy components
based on the discussion are: types of data accepted by an LTA; types of data
operated upon by an LTA and nature of that operation; access control policy;
refresh operation triggers; types and characteristics of refresh mechanisms
used.  

2) Are archive policies enforced on a per document basis or per LTA basis?
	- It seems like there are some policy components that should be per
document (e.g. archivation period) and others that are LTA-wide (e.g. TSA
used to generate timestamps, 

3) If archive policies are named, what is the namespace?

4) What components of an archive policy can be specified by a submitter (or
modifier)?

5) Do different LTAs share named archive policies?
	- This seems like a likely scenario.

6) Cryptographic maintenance policies were described in detail (see below
with responses).

> "4.X Cryptographic maintenance
> 
> 4.X.1  Functional requirements
> 
>     A long term archive service must maintain the cryptographic
>     validity of its evidence records. It needs to perform the 
> following
>     basic operations:
> 
>         - attach cryptographic maintenance parameters to one or a set
>           of archived packages,
> 
>         - apply the cryptographic maintenance policy referenced within
>           the cryptographic maintenance parameters to maintain the
>           validity of its evidence records using the critical
>           cryptographic parameters,
> 
>         - periodically apply the original cryptographic maintenance
>           policy using the critical cryptographic parameters,

"Original" should be "current".  Once the policy is changed the original
policy won't be reapplied.
 
>         - periodically apply a new cryptographic maintenance policy
>           should the previous cryptographic maintenance policy become
>           weak or inappropriate.
> 
>     When an archived data objet is submitted to a long term archive
>     service with cryptographic maintenance parameters, then the long
>     term archive service shall either maintain the cryptographic
>     validity of that archived data objet or refuse to accept the
>     service. If it accepts, then it needs to perform the following
>     basic operations:
> 
<snip redundant text>
> 
> 
> 4.X.1  Rational
> 
> Maintenance of the validity of archived packages is a necessary basic 
> function of a long-term archive service.
> 
> Maintenance of the validity of archived data objets is an 
> optional function 
> of a long-term archive service".
> 
> 
> 10. A new section should be introduced to address the 
> requirement of some 
> data structures. Proposed text;
> 
> " Y. Requirements on some data objects
> 
> Y.1 Requirements on cryptographic maintenance policies
> 
> A cryptographic maintenance policy:
> 
>     - must be unambiguously identified by an object identifier
>       (e.g. an OID),

Suggest "must be unambiguously identified (e.g. an OID)".  No need to
require OIDs.
 
>     - must include a validity period,
> 
>     - must specify how the necessary bindings to the time scale will
>       be guaranteed, for example it can specify the 
> Time-Stamping Units
>       (TSU) recognized under that policy,
> 
>     - may unambiguously reference a sequence of one or more previously
>       defined cryptographic maintenance policies.

For what purpose?

> 
> Y.2 Requirements on critical cryptographic parameters
> 
> Critical cryptographic parameters shall include data objects 
> describing all 
> the algorithms, and the associated key lengths used in the 
> object to which 
> the critical cryptographic parameters are associated. These 
> data objects may 
> be in the form of data objects identified using an OID, and 
> may include one 
> or more algorithm specific parameters.
>
> Y.3 Requirements on cryptographic maintenance parameters
> 
> Cryptographic maintenance parameters shall include two components:
> 
>     - critical cryptographic parameters, and
> 
>     - an unambiguous reference to one cryptographic 
> maintenance policy.
> 
>
> 11. In formation should be added to address cryptographic 
> maintenance issues 
> in case a hash function exhibits collisions. Proposed text to 
> be included in 
> the security considerations section:
> 
> "Cryptographic maintenance issues in case a hash function 
> exhibits collisions
> 
> Submitters may submit:
> 
>     1) signed data and their associated signatures, or
>     2) signatures only (i.e. without the signed data).
> 
> In case the hash function used to compute the digital 
> signature over the 
> original data exhibits collisions, it is necessary to 
> recompute a hash of 
> that original data using another hash function. This is not 
> feasible if 
> signatures only are submitted (i.e. without the signed data)".