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
