Subject: RE: Cross review of draft ERS from LTANS WG until Jan 23 rd

From: Carl Wallace <[email-masked]>
Date: Tue, 16 Jan 2007 06:38:44 -0500

inline...

  _____  

From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 3:27 AM
To: Carl Wallace; [email-masked]
Cc: [email-masked]; 'Russ Housley'
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd

Carl,
 
ERS + LTAP do not meet the requirements. 
[CRW] ERS is currently the focus.  Not LTAP. 
 
 <snip> 
The archival policy, the archival time period and the crypto maintenance
policy are never mentioned. 
Since they are currently not part of ERS, they appear nowhere.
[CRW] "Policy" is cited throughout and is included in the RequestInformation
structure.  "Archival policy" and "crypto maintenance policy" are not
distinguished.  They should be, but not in ERS.
 
It is never mentioned that a response is signed.  
 
ERS + LTAP contain no signature from a LTA agent. 
[CRW] See the following in section 8: "These data are optionally
encapsulated by CMS content types that provide for authentication and/or
confidentiality, e.g.  SignedData or EnvelopedData."  
 
About the DELETE operation, what is worse is the following sentence: "Note
that this does not mean that 
the server does not maintain a trace record of the delete operation". A
trace record would not be sufficient. 
Deletion of an archive shall normally not happen, since the LTA is trusted
to keep the data until the end of 
the archive period. A signed permission of deletion, by the owner of the
data shall be given, before deletion 
can occur. This is mentioned nowhere in the document.
 
[CRW] This should be added.
 
Once again, the current set of documents does not meet the requirements.
 
I guess you reacted too quickly to my proposal from yesterday and you should
pay more attention to it. 
[CRW] Most of your suggestions apply to a different document, in my opinion.
I do think you were correct w.r.t. inclusion of an indication of policy in
the ArchiveTimeStamp layer.  Towards that end, my counter-proposal yesterday
may serve us better if we exchange the optional OBJECT IDENTIFIER field for
an optional Attributes field, where policy could be an instance:
 
   ArchiveTimeStamp ::= SEQUENCE { 
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, 
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, 
     attributes          [2] Attributes OPTIONAL, 
     timeStamp       ContentInfo} 
 
I think the other matters can and should be addressed in the context of
LTAP.
 
Carl

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 16 Jan 2007 14:52:42 +0100

>     [CRW] ERS is currently the focus.  Not LTAP. 
Right.
>     encapsulated by CMS content types that provide for authentication
>     and/or confidentiality, e.g.  SignedData or EnvelopedData."  
>      
>     About the DELETE operation, what is worse is the following
>     sentence: "Note that this does not mean that
>     the server does not maintain a trace record of the delete
>     operation". A trace record would not be sufficient.
>     Deletion of an archive shall normally not happen, since the LTA is
>     trusted to keep the data until the end of
>     the archive period. A signed permission of deletion, by the owner
>     of the data shall be given, before deletion
The details how a delete request is authenticated is outside of scope of 
LTAP as well as management of ownerships etc.
A trace record means: "At this place there had been some data which can 
be described by (list of some metadata),
they had been deleted (metadata about that fact)." It is not the backend 
LTA that creates all these metedata,
the frontend that authenticates the request prepares some of them. The 
LTA does not make complicated decisions.

An example of a higher level front end protocol on can take something 
like the French proposal
of the National Archives.

Peter