RE: SCVP 16 comments deadline

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

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