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:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 1:16 PM > To: Tobias Gondrom > Cc: Carl Wallace; General Area Review Team; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > 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:[EMAIL PROTECTED] > >> Sent: Friday, June 01, 2007 11:28 AM > >> To: Carl Wallace > >> Cc: Tobias Gondrom; General Area Review Team; > >> [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; > >> 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 [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
