[Gen-art] RE: Gen-ART review of draft-ietf-ltans-ers-13.txt

["Tobias Gondrom" <[e-mail]>]

Ok. Thank you, Carl and Brian. 

I just submitted draft-ietf-ltans-ers-15.txt with the change as proposed
by Brian. 

 

Best regards and have a nice weekend, Tobias

 

 

 

 

________________________________

From: Carl Wallace [mailto:[e-mail]] 
Sent: Friday, June 01, 2007 5:55 PM
To: Tobias Gondrom
Cc: General Area Review Team; [e-mail];
[e-mail]; Tim Polk; Brian E Carpenter
Subject: RE: Gen-ART review of draft-ietf-ltans-ers-13.txt

 

I like Brian's clarification that the verification data be preserved but
that it is not required to appear in the timestamp. 

> -----Original Message----- 
> From: Tobias Gondrom [mailto:[e-mail]] 
> Sent: Friday, June 01, 2007 10:10 AM 
> To: Carl Wallace 
> Cc: General Area Review Team; 
> [e-mail]; 
> [e-mail]; Tim Polk; Brian E Carpenter 
> Subject: RE: Gen-ART review of draft-ietf-ltans-ers-13.txt 
> 
> Ok. 
> So, than this up to your judgement, Carl. 
> - Tobias 
> 
> 
> Ps.: if you tell me to do so, I will submit a revised draft 
> right away, otherwise Tim can progress the draft. 
> 
> 
> 
> > -----Original Message----- 
> > From: Brian E Carpenter [mailto:[e-mail]] 
> > Sent: Friday, June 01, 2007 4:03 PM 
> > To: Tobias Gondrom 
> > Cc: Carl Wallace; General Area Review Team; 
> > [e-mail]; 
> [e-mail]; 
> > Tim Polk 
> > Subject: Re: Gen-ART review of draft-ietf-ltans-ers-13.txt 
> > 
> > Thanks. I believe there is an issue of clarity here, but as always, 
> > please take guidance from the document shepherd. 
> > 
> >      Brian 
> > 
> > 
> > On 2007-06-01 15:20, Tobias Gondrom wrote: 
> > > Hello Brian, 
> > > 
> > > Concerning the sentence in section 4.2: 
> > > I do not see a big difference between your proposal: 
> > > "The data (e.g. certificates, CRLs or OCSP-Responses) needed to 
> verify 
> > > the timestamp MUST be preserved, and SHOULD be stored in the 
> timestamp 
> > > itself unless this causes unnecessary duplication." 
> > > 
> > > And the existing text: 
> > > "The data (e.g. certificates, CRLs or OCSP-Responses) needed to 
> verify 
> > > the timestamp SHOULD be stored in the timestamp itself or MUST be 
> > > preserved otherwise." 
> > > 
> > > Although I do not see the need to change it, I can see no damage 
> either. 
> > > 
> > > So, if this re-wording solves your comment, we can make 
> the change. 
> > > 
> > > Ok? 
> > > 
> > > Tobias 
> > > 
> > > 
> > > 
> > >> -----Original Message----- 
> > >> From: Brian E Carpenter [mailto:[e-mail]] 
> > >> Sent: Friday, June 01, 2007 1:16 PM 
> > >> To: Tobias Gondrom 
> > >> Cc: Carl Wallace; General Area Review Team; 
> > >> [e-mail]; 
> > > [e-mail]; 
> > >> Tim Polk 
> > >> Subject: Re: Gen-ART review of draft-ietf-ltans-ers-13.txt 
> > >> 
> > >> On 2007-06-01 12:11, Tobias Gondrom wrote: 
> > >>> Hello Brian, 
> > >>> Answer/Comments inline. 
> > >>> Tobias 
> > >>> 
> > >>> Ps.: I hope you do not feel your comment got ignored, cause that

> has 
> > >>> never been my intention. (I just thought my explanation was 
> > > satisfying, 
> > >>> as you indicated in your email May-22 and closed the item 
> > > accordingly.) 
> > >> No problem at all - I just thought about it some more. 
> We Gen-ART 
> > >> reviewers have a habit of looking at SHOULD and SHOULD NOT quite 
> > >> closely, 
> > > because 
> > >> we know that they can cause indecision among implementers. For 
> > > example, 
> > >> you could say something like this: 
> > >> 
> > >> The data (e.g. certificates, CRLs or OCSP-Responses) needed to 
> verify 
> > >> the timestamp MUST be preserved, and SHOULD be stored in the 
> timestamp 
> > >> itself unless this causes unnecessary duplication. 
> > >> 
> > >> It's up to you, I am not insisting on a change. 
> > >> 
> > >>      Brian 
> > >> 
> > >> 
> > >> 
> > >>> 
> > >>>> -----Original Message----- 
> > >>>> From: Brian E Carpenter [mailto:[e-mail]] 
> > >>>> Sent: Friday, June 01, 2007 11:28 AM 
> > >>>> To: Carl Wallace 
> > >>>> Cc: Tobias Gondrom; General Area Review Team; 
> > >>>> [e-mail]; 
> > >>> [e-mail]; 
> > >>>> Tim Polk 
> > >>>> Subject: Re: Gen-ART review of draft-ietf-ltans-ers-13.txt 
> > >>>> 
> > >>>> Triggered by seeing -14 come out: 
> > >>>> 
> > >>>> On 2007-05-21 20:44, Carl Wallace wrote: 
> > >>>>>>> 1. At the end of section 4.2: 
> > >>>>>>> 
> > >>>>>>>  The data (e.g. certificates, CRLs or OCSP-Responses) 
> > >>>>>> needed to verify 
> > >>>>>>> the timestamp SHOULD be stored in the timestamp 
> itself or MUST 
> > > be 
> > >>>>>>> preserved otherwise. 
> > >>>>>>> 
> > >>>>>>> I find this insufficiently clear. When would it be 
> > >>>>>> acceptable not to 
> > >>>>>>> store these data in the timestamp, and if not done so, how 
> > >>>>>> would the 
> > >>>>>>> retriever know where to look? 
> > >>>>>> [tg]: There are three main reasons why we did intentionally 
> > >>>>>> write this up in this level of detail: 
> > >>>>>> At first, most of the verification of a 
> RFC3161-timestamp has 
> > >>>>>> been documented very well in the timestamp and CMS 
> > >>>>>> specifications. Second, ERS is open for other timestamps as 
> > >>>>>> well (e.g. ISO-18014-x) and they may (and do) require other 
> > >>>>>> verification data than RFC3161, plus these other formats may 
> > >>>>>> not be able to store all the necessary information for 
> > >>>>>> verification inside their data structures. 
> > >>>>>> And third, as some of the verification data may be 
> dependent on 
> > >>>>>> the use case and country where it is verified, the 
> WG works on 
> > >>>>>> the I-D 
> > >>>>>> 
> http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate- 
> > >>>>>> 01.txt to describe the verification and the required data in 
> > >>>>>> more detail. 
> > >>>>> In addition to the above, the "SHOULD be stored in the 
> timestamp" 
> > >>>>> recommendation is present in the spec because this is the 
> easiest 
> > >>>> option. 
> > >>>>> If the timestamp contains all of the verification data, then 
> there 
> > >>> is 
> > >>>> less 
> > >>>>> work for the verifier to perform.  However, this also freezes 
> the 
> > >>>>> verification context (if this is the only means of preserving 
> > >>>> verification 
> > >>>>> data).  There is a companion specification that defines how to

> use 
> > >>> SCVP 
> > >>>> and 
> > >>>>> ERS to preserve certificates and CRLs independent of 
> a data item 
> > >>> that is 
> > >>>>> archived.  This has a few benefits, including decreasing the 
> > > storage 
> > >>>> burden 
> > >>>>> on the archive and avoiding freezing the validation context. 
> > >>>>> 
> > >>>> I'm still a little unhappy about the SHOULD. How does an 
> > > implementor 
> > >>> know 
> > >>>> that it's OK to ignore the SHOULD? If the data is not stored in

> the 
> > >>>> timestamp, 
> > >>>> shouldn't you say that a pointer to the data MUST be stored in 
> the 
> > >>>> timestamp? 
> > >>> No, this would not be good. For verification data, we have today

> > > what 
> > >>> you might call like "implicit pointers" in the 
> timestamp, i.e. the 
> > >>> timestamp authority source name etc. gives you the information 
> from 
> > >>> where to receive the additional verification data like its 
> > > certificate 
> > >>> and CRL/OCSP. 
> > >>> So with the timestamp this is already implicitly known and it 
> would 
> > > be a 
> > >>> bad idea to force another explicit pointer to the structure. 
> > >>> 
> > >>> 
> > >>> (additional personal note: in general a verification 
> procedure of 
> > > the 
> > >>> timestamp must also include this data (certificate and (CRL OR 
> > > OCSP). 
> > >>> This can be done by retrieving the information from an online 
> source 
> > >>> (defined by the TSA name and address) or from the data 
> structures 
> of 
> > > the 
> > >>> timestamp or another source (e.g. a file store at the 
> verification 
> > >>> entity). 
> > >>> For infinite times it is obvious that the online source will no 
> > > longer 
> > >>> be available. But many use cases require a long (but 
> not infinite) 
> > >>> storage time where renewal is absolutely necessary, but 
> where the 
> > >>> business scenario guarantees that the verification data will be 
> > >>> available for the whole time. (e.g. some TSA guarantee 
> (including 
> a 
> > >>> government continuation guarantee) that the service will be 
> > > available 
> > >>> online for a specified time, e.g. 30 years, even if the 
> TSA closes 
> > >>> down.) 
> > >>> This again leads to the term SHOULD but not MUST.) 
> > >>> 
> > >>> 
> > > 
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art