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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Jun 2007 11:28:02 +0200

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?

     Brian

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Tobias Gondrom" <[email-masked]>
Date: Fri, 1 Jun 2007 12:11:52 +0200

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.)

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 11:28 AM
> To: Carl Wallace
> Cc: Tobias Gondrom; General Area Review Team;
> [email-masked];
[email-masked];
> Tim Polk
> Subject: Re: Gen-ART review of draft-ietf-ltans-ers-13.txt
> 
> > If the timestamp contains all of the verification data, then there
is
> less
> > data).  There is a companion specification that defines how to use
SCVP
> and

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.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Jun 2007 13:16:24 +0200

> 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

---

From: "Tobias Gondrom" <[email-masked]>
Date: Fri, 1 Jun 2007 15:20:09 +0200

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

> Sent: Friday, June 01, 2007 1:16 PM
> To: Tobias Gondrom
> Cc: Carl Wallace; General Area Review Team;
> >>> archived.  This has a few benefits, including decreasing the
storage
> >> burden
> >> I'm still a little unhappy about the SHOULD. How does an
implementor
> > know

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Jun 2007 16:03:08 +0200

Thanks. I believe there is an issue of clarity here,
but as always, please take guidance from the document
shepherd.

     Brian

---

From: "Tobias Gondrom" <[email-masked]>
Date: Fri, 1 Jun 2007 16:10:11 +0200

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. 

> Sent: Friday, June 01, 2007 4:03 PM
> To: Tobias Gondrom
> >>>>> recommendation is present in the spec because this is the
easiest
> >>>> option.
> >>>> 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?
> >>> So with the timestamp this is already implicitly known and it
would
> > be a
> >>> (defined by the TSA name and address) or from the data structures
of
> > the