However to get to the bottom line, is there a specific problem with the
text in section 3.1.2
Trevor
* -----Original Message-----
* From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
* Sent: Thursday, December 09, 2004 2:22 PM
* To: Trevor Freeman
* Cc: ietf-pkix@xxxxxxx
* Subject: Re: SCVP 16 comments deadline
*
* Trevor,
*
* I must say that I agree with Seth and Denis. I was under the
impression
* that "Do revocation status checking on the certification path" really
* meant "build and validated certification path to a trust anchor and do
* revocation status checking on the certification path". While I can
see
* that there may be circumstances in which one would request a validated
* certification path without requiring revocation status checking, I
can't
* see requesting revocation status checking without requesting that the
* path be validated.
*
* It is certainly the case that one can not "do revocation status
checking
* on the certification path" without also building a certification path.
* Since the client can not provide a certification path, revocation
status
* checking must be performed on a path that is built by the server. I
* suppose you could argue that this simply means that a well formed
query
* can not include the id-stc-build-status-checked-pkc-path without also
* including either the id-stc-build-pkc-path or
* id-stc-build-valid-pkc-path check. But, I see see the need for this.
*
* A DPD client would include the id-stc-build-pkc-path along with the
* id-swb-pkc-best-cert-path and/or id-swb-pkc-revocation-info wantBacks.
* If the DPD client included the id-swb-pkc-revocation-info wantBack, it
* wouldn't need to also include the id-stc-build-status-checked-pkc-path
* check. If the DPD client did not include the
id-swb-pkc-revocation-info
* wantBack, then would not include the
* id-stc-build-status-checked-pkc-path check.
*
* So, I would argue that the id-swb-pkc-revocation-info wantBack would
* only be used in the case that the client was requesting a validated
* certification path. The way that I had interpreted the currently
* defined checks items, an SCVP query would only include one check since
* each successive check included the requirements of the previous one:
* id-stc-build-valid-pkc-path included the requirement to build a path
* (id-stc-build-pkc-path) and id-stc-build-status-checked-pkc-path
* included the requirement to build a validated path
* (id-stc-build-valid-pkc-path).
*
* Under what circumstances can you envision a client wanting the server
to
* do revocation status checking on a certification path (that is
* constructed by the server) without also including a requirement that
the
* certification path be validated? If there are no reasonable
* circumstances in which a client would make such a query, why is it
* necessary for clients to be able to construct such a query?
*
* Dave
*
* Trevor Freeman wrote:
*
* >Hi Seth,
* >A server can always go beyond what the client asked for. I don't see
* >that as strictly necessary in all cases such as if the client just
asks
* >for revocation. Untimely is a matter of local server policy. What the
* >server cannot do is return status or errors relating to the other
* >activities which were beyond the request scope.
* >Trevor
* >
* While it might make sense for a client to only ask for revocation
* checking if the client could specify the certification path, it does
not
* seem to make sense given that the server chooses the certification
path
* for which revocation status checking will be performed. If the client
* wants to specify a set of certificates for which it only wants to know
* the revocation status, that is what OCSP is for.
*
* >
* >* -----Original Message-----
* >* From: Seth Hitchings [mailto:shitchings@xxxxxxxxxxxxxx]
* >* Sent: Wednesday, December 08, 2004 11:34 AM
* >* To: Trevor Freeman
* >* Cc: ietf-pkix@xxxxxxx
* >* Subject: RE: SCVP 16 comments deadline
* >*
* >* Trevor,
* >*
* >* For clarification, I assume that doing revocation status checks on
a
* path
* >* implies building
* >* a validated path?
* >*
* >* If I am correct, in what case would a client ever send more than
one
* >* check?
* >*
* >* Seth
* >*
* >* -----Original Message-----
* >* From: owner-ietf-pkix@xxxxxxxxxxxx
* >[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
* >* On Behalf Of
* >* Trevor Freeman
* >* Sent: Wednesday, December 08, 2004 1:42 PM
* >* To: Denis Pinkas
* >* Cc: ietf-pkix@xxxxxxx
* >* Subject: RE: SCVP 16 comments deadline
* >*
* >*
* >* Denis,
* >* I know of several systems who's policy is never to revoke the
identity
* >* certificate because
* >* they have other mechanisms to address the issue.
* >* They are using authorization bound to the identity and they either
rely
* on
* >* short lived
* >* authorization assertions or revoke the authorization privilege
* assonated
* >* with the
* >* identity. Therefore in those cases not checking the revocation
status
* of
* >* the certificate
* >* makes perfect sense.
* >* Trevor
* >*
* >* * -----Original Message-----
* >* * From: owner-ietf-pkix@xxxxxxxxxxxx
* >* [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
* >* * On Behalf Of Denis Pinkas
* >* * Sent: Wednesday, December 08, 2004 8:01 AM
* >* * To: Trevor Freeman
* >* * Cc: ietf-pkix@xxxxxxx
* >* * Subject: Re: SCVP 16 comments deadline
* >* *
* >* *
* >* * Trevor,
* >* *
* >* * > Hi Denis,
* >* * > Below are responses to 1-16. Others will follow later.
* >* *
* >* * I am pleased that you accepted comments 13, 14, 15 and 16.
* >* * Among this list, I have a further remark on comment 4.
* >* *
* >* * > * 4. Page 13. Typo. Section 3.1.2 "checks"
* >* * > * The two following lines are in fact one line:
* >* * > *
* >* * > * Change:
* >* * > *
* >* * > * - Build a validated certification path to a trust
anchor;
* and
* >* * > *
* >* * > * - Do revocation status checks on the certification path.
* >* * > *
* >* * > * into:
* >* * > *
* >* * > * - Build a validated certification path to a trust anchor
and
* >* * > * do revocation status checks on the certification path.
* >* * > *
* >* * > [TF] Since this paragraph is listing the possible checks and
* building
* >* a
* >* * > path is a separate check to revocation checking, I think the
* current
* >* * > text is more accurate.
* >* *
* >* * I agree that "building a path is a separate check to revocation
* >* checking",
* >* * but revocation checking without building a validated path does
not
* make
* >* * sense.
* >* *
* >* * The full text currently is:
* >* *
* >* * - Build a certification path to a trust anchor;
* >* *
* >* * - Build a validated certification path to a trust anchor;
and
* >* *
* >* * - Do revocation status checks on the certification path.
* >* *
* >* * The full text should be:
* >* *
* >* * - Build a certification path to a trust anchor;
* >* *
* >* * - Build a validated certification path to a trust anchor;
and
* >* * do revocation status checks on the certification path.
* >* *
* >* * Denis
* >*
* >
* >
* >
*