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

[Carl Wallace <[e-mail]>]

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