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

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

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