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

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

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:[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