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

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

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