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

[Brian E Carpenter <[e-mail]>]

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