ietf-smime
[Top] [All Lists]

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

2007-01-16 05:11:29
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