[Top] [All Lists]

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

2007-01-16 09:36:29


Small comment: 

I agree with, that ARI and validate is not mature.

I agree that LTAP still needs some improvement for WGLC - though I
believe it is in good shape.

I obviously do not agree with that ERS is not mature. 

And I totally disagree that ERS cannot be sent alone to the IESG. 


Concerning the last two disagreements: 

1. As Carl already pointed out it seems there might be a
misunderstanding of the relationship between ERS and REQS: 

ERS is definitely not the complete answer to all requirements from REQS,
but fulfils its part. Other things shall be defined by LTAP and some
REQS may even be addressed at a later time (or only by individual
implementations but not by an I-D). (The goal of REQS is to help choose
the right technical solutions and approach by defining the objective
targets for the specifications.)

2. ERS as the data structure for the records is valuable on its own and
has with intent been only loosely coupled with LTAP. So we can progress
ERS. This makes the work of the WG easier and more efficient as we then
can focus on LTAP and ARI and validate (note: the last two are only
intended to be informational).


Thanks, Tobias




From: owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis 
Sent: Tuesday, January 16, 2007 4:32 PM
To: Carl Wallace; ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd




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
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


        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.