ietf-smime
[Top] [All Lists]

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

2007-01-16 09:13:02
Carl,

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 
e-mails
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.

Denis  




inline...




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


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