Subject: RE: Comments on LTANS documents

From: "Carl Wallace" <[email-masked]>
Date: Wed, 4 Aug 2004 15:15:56 -0400

<large snip>
> Agree. We must differentiate between searching and 
> retrieving. But it is important to identify unambigously the 
> point of retrieval, otherwise you may get two different 
> documents from two different sources both claiming that they 
> are the archived documents.

Why is it important to unambiguously identify the point of retrieval?  The
point of retrieval might change over time.  Do you mean unambiguously
identify the data object to retrieve?

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 4 Aug 2004 15:56:45 -0400

Denis,

Thanks for your review of the document set.  We will address your comments
on the archive requirements document in the next version.  A few comments
are in-line below.

Carl

<snip>
> As far as the WHO is concerned, there are:
> 
>     1) the person or the application who did the deposit,
> 
>     2) the persons or the applications allowed to retrieve the data
>        (not necessarily the same as 1))
> 
>     3) the persons or the applications wishing to make sure that
>        some data originates from a given Archiving Unit (Arch-Unit)
>        under the responsibility of a given Archiving Authority
>        (Arch-A) and has been stored by it at a given point of time.
> 
> The difference between the above "players" should be 
> introduced in the documents.

The current text addresses each of 1, 2 and 3 as submitter, retriever and
arbitrator.  There are at least two outstanding roles: folks who can search
and folks who can manage a particular entry in an archive (e.g. shorten the
retention period).
 
<snip>
 
> 
> 3. When a person or an application makes deposit, it is of primary 
> importance that it gets back a "proof of deposit" from an 
> Arch-Unit. In case 
> the deposited data would be lost, then the Arch-A would be 
> responsible from 
> the loss.
> 
> Note that AFNOR has done some work to standardize different 
> kinds of proof, 
> including a "proof of deposit" with a full description of the 
> data structure 
> of that proof using ASN.1. This work should be published soon 
> as an AFNOR 
> Experimental Standard.
> 
> The concept of a "proof of deposit" should be introduced in 
> the documents.

The concept is present in the document in 4.1.1: 

	"Following submission, the service must provide a value that can be
   used to retrieve the archived data and/or associated evidence."

	"The acknowledgement of a successful submission should permit the
   submitter to verify that the correct data was received by the service
   for preservation."

"Proof of deposit" is a more descriptive way to label the concept.

> 
> 4. The deposit is made for a given archiving time period. 
> This period cannot 
> be shortened, unless the person who made the deposit signs a document 
> allowing the Arch-A to do so. In case the person who did the deposit 
> complains later on, then the Arch-A would be able to 
> demonstrate that the 
> archiving period has been shortened.
> 
> This concept should be introduced in the documents.

I don't think the requirements doc (or possibly any of the docs) should
mandate that the submitter is the only entity who should be allowed to
perform this operation.  I agree that concepts related to management of
entries in an archive need to be better addressed.
 
> 
> 5. The documents states that " a long-term archive service 
> provides material 
> needed to demonstrate the existence and integrity of data 
> object". This 
> definition is far from sufficient, since, it is missing two 
> dimensions:
> 
>      1) the fact to demonstrate that the archive was made
>        *at a given time*,

True.

> 
>      2) the fact to demonstrate that the archived data originates
>         *from a given Arch-Unit and Arch-A*.

While there is no subdivision similar to "Arch-Unit" and "Arch-A" in the
doc, the notion of identifying the archive service provider in the evidence
is present in 4.1.1.
 
> A better definition is present in section 4.3.1.
> 
> 
> 6. A major component which is not sufficiently described is 
> the Archive 
> Policy (Arch-Pol). The components of an Arch-Pol should be 
> first identified, 
> before attempting to define any data structure or protocol. 
> Section 4.4.2 
> should grow from 3 lines to one or two pages and should be 
> introduced much 
> earlier in the document.

Agree that elements of policy remain largely unexplored in this group and
need attention.

> 
> 7. One of the several aspects to be developed about the 
> Arch-Pol would be 
> how to relate the Arch-Pol under which the document is 
> retrieved 30 years 
> later to the initial Arch-Pol under which the document has be 
> deposited. 
> These policies cannot be the same, since, for example Time-Stamping 
> Authorities used 30 years later could not be known initially. 
> There may be a 
> chain of Arch-Pol to consider.

For most (all?) pieces of evidence, the notion has been to include the data
in the evidence structure itself (e.g. certs/crls/trust anchors).  Is there
any reason not to treat policy in a similar way?  Policy may be another
"special" type of data similar to trust anchors that an archive must handle.
I don't think using a different (or simply rekeyed) TSA constitutes a change
in policy.  Policy chains may require manual consideration.
 
> 
> 8. One of the several aspects to be developed about the 
> Arch-Pol would be 
> the policy for the "automatic" maintenance of archived data.
> 
> One obvious possibility is to time-stamp the archived data at 
> the time of 
> the deposit. One or more time-stamps tokens (TST) may be 
> applied (more than 
> one time-stamp token is not addressed in the documents).
> 
> For the maintenance of these TSTs, there are then two options:
> 
>      a) apply a new TST before the end of the validity period of the
>         TSU certificate and then capture the CRL of the CA which has
>         produced the TSU certificate in order to demonstrate that the
>         TSU certificate was not revoked at the time the new TST was
>         applied (this point is not addressed in any of the current
>         two documents).
> 
>      b) rely on the Certificate Policy of the CA which has produced
>         the TSU certificate, which will impose a specific 
> protection for
>         the TSU private key (key generation mandatory within 
> a security
>         module and no key export possible, mandatory 
> zeroization of the
>         private key at the end of the private key usage period. Once
>         the TSU certificate has expired, then the private key from the
>         TSU cannot be compromised anymore, except using brute force
>         attacks. In practice, the Archiving Unit will need to capture
>         the revocation status of the TSU certificate (usually a CRL),
>         once the TSU certificate has expired, in order to demonstrate
>         that the TSU certificate was not revoked at the end of the
>         validity period of the TSU certificate (this point is not
>         addressed in any of the current two documents).
> 

I'm not sure this is material that belongs in the requirements document.
Certainly the triggers related to refresh operations (if used) need to be
addressed somewhere - probably in the spec defining the mechanism.   
 
> 9. When an archived data is retrieved, with the proof it was 
> archived at a 
> given time, then the proof that the last TST is still valid has to be 
> produced. In practice this means (for case a) above) that the 
> *current* CRL 
> of the last TSU has to be produced (this point is not 
> addressed in any of 
> the current two documents).

Correct.  Additionally, same thing holds true for trust anchor usage (i.e.
most recent timestamp is validated to a current TA as opposed to historical
TA).  As above, this will most likely be addressed in a specification
document rather than in the requirements document.

<snip>

> 14. Transfer from one archive service to another one may only 
> apply for the 
> same or compatible Archive Policies (Arch-Pol).

Why?  The value of data (or financial standing of the data sponsor) may
change over time such that it is OK to use less rigorous archive methods,
i.e. different and non-compatible policies.  This seems more like a policy
instantiation than something for the the requirements doc.

> 
> 15. Disclosing or not the archived data to the Arch-Unit is 
> an interesting 
> topic. Three cases should be identified:
> 
>      1) the archived data is public data,
> 
>      2) the archived data is private data, and only a hash of it
>         is communicated,

A hash may only be transferred to a TSA but an Arch-Unit/TAA/AS/SAS would
receive or already possess the data (either encrypted or plaintext).

<snip> 
> 16. The documents states "where groups of data objects are submitted, 
> non-repudiation proof [of what ?] must still be available for 
> each archived 
> data separately". This is not a MUST. This MAY be a feature.

Do you mean multi-object submission is a may or the ability to verify each
separately is a may?  I think the statement in the doc is correct.
 
<snip>