Subject: RE: SCVP 16 comments deadline

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 8 Dec 2004 11:42:06 -0800

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

* -----Original Message-----
* From: Seth Hitchings [mailto:[email-masked]]
* Sent: Wednesday, December 08, 2004 11:34 AM
* To: Trevor Freeman
* Cc: [email-masked]
* 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: [email-masked]
[mailto:[email-masked]]
* On Behalf Of
* Trevor Freeman
* Sent: Wednesday, December 08, 2004 1:42 PM
* To: Denis Pinkas
* Cc: [email-masked]
* 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: [email-masked]
* [mailto:[email-masked]]
* * On Behalf Of Denis Pinkas
* * Sent: Wednesday, December 08, 2004 8:01 AM
* * To: Trevor Freeman
* * Cc: [email-masked]
* * 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
*

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 09 Dec 2004 17:22:01 -0500

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

>activities which  were beyond the request scope.
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.

>* For clarification, I assume that doing revocation status checks on a path
>* implies building
>* a validated path?
>* 
>* 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
>* 
>* * > *      - Build a validated certification path to a trust anchor; and
>* * > *
>* * > *      - Build a validated certification path to a trust anchor and
>* * > [TF] Since this paragraph is listing the possible checks and building
>* a
>* * > path is a separate check to revocation checking, I think the current
>* * but revocation checking without building a validated path does not make
>* * sense.
>* *