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:[EMAIL PROTECTED]
Sent: Friday, June 01, 2007 1:16 PM
To: Tobias Gondrom
Cc: Carl Wallace; General Area Review Team;
[EMAIL PROTECTED];
[EMAIL PROTECTED];
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:[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
