Re: Extended Key Usage and path validation

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

thayes@netscape.com (Terry Hayes) writes:

>Since the processing of the EKU extension is intended to provide information
>on both the EE (can it participate in this PKI application) and the CA (can it
>issue the certificate), the extension is checked at all points in the path.
>Except for the trusted anchor all CA certificates in the path must have the
>EKU value corresponding with the current usage.  (Actually, CA certificates
>without and EKU extension are "grandfathered" for SSL and S/MIME, but not
>object signing).  The result is effectively the intersection of the EKU values
>in the path.

I used to do this as well, until someone complained that this was broken since
I was rejecting some otherwise valid certs as invalid.  Reading RFC 2459, I had
to agree that it probably was broken (at least in terms of RFC 2459) since the
EKU would apply to the CA's key, not the keys in the certs it issues.  I think
it's more logical to have it apply to certs it issues, but then you have the
problem that in a CA cert, KU applies to the CA's key and EKU applies to the
issued cert's keys.  Son-of-2459 could do with some added clarification in this
area, although given the current ambiguity and the fact that there appear to be
implementations which have either intepretation, it may be a bit late.  Looks
like the style guide needs an update in this area...

Peter.