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