[Top] [All Lists]

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

2007-01-16 09:13:02

I will have lo leave the discussion here for a few days, since I need to attend 
different meetings.

This leaves you more time to look again at the arguments explained in my three 
and to my proposal where the new proposed ASN.1 fulfils the LTANS requirements 
whereas ERS does not.

I simply reiterate my position:
 - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements. 
 - ERS is not mature.
 - LTAP is not mature.
 - ARI is not mature.
 - validate is not mature.
 - ERS needs major revisions. 
 - ERS cannot be sent alone to the IESG.



From: Denis Pinkas [mailto:denis(_dot_)pinkas(_at_)bull(_dot_)net] 
Sent: Tuesday, January 16, 2007 3:27 AM
To: Carl Wallace; ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org; 'Russ Housley'
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd


ERS + LTAP do not meet the requirements. 
[CRW] ERS is currently the focus.  Not LTAP. 

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.