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

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

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