Re: Extended Key Usage and path validation

[thayes@xxxxxxxxxxxx (Terry Hayes)]

Netscape's processing of the EKU extension requires
that every certificate in the chain has a particular EKU value in some cases. 
The EKU extension is being used as a replacement for an older Netscape-defined
extension called "Netscape Certificate Type".  This extension indicated the
types of PKI applications that the certificate could be used for, and for
CAs indicated whether the CA was allowed to issue certificates for that PKI
application.  The older extension covered SSL (client and server), S/MIME
and "object signing" (for secure Java applications).

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.

That's the current implementation.  I believe that IE does similar processing. 
I do agree with Stephen Kent that this might be viewed as conflicting with
the key usage that applies to the CA itself.  That is, the presence of an
EKU extension value for S/MIME in the CA certificate might be interpreted
as allowing the CA to use the key for signing S/MIME messages, rather than
indicating that it can issued S/MIME certificates.

In fact, I probably could be convinced that Certificate Policies is the correct
way of checking the validity of a path for a particular purpose.  An application
might require that a particular policy value is present in a certificate
path before S/MIME operations would be allowed using that certificate.  X.509
and the various PKIX RFCs already define how to validate the policy extension.

The problem with using certificate policy values for this purpose is that
there is no standard policy OID that is defined to represent S/MIME or SSL
operations.  In order to encourage wide interoperability of these applications,
the software must come with certain values preinstalled.  Most users don't
have the understanding necessary or the desire to configure their browser
or messaging software with PKI configuration data.  If policy values are
used to control this, a standard value must be defined and used by all PKI
deployments, to represent basic S/MIME or SSL enablement.

We could probably "steal" the OID from the EKU definition, and use it in
the context of certificate policy.  I don't see any problem with doing this;
it would cleanly separate the path validation parameters from the intended
end-use of the key.

Terry Hayes
Netscape Communications Corp.

Jean-Marc Desperrier wrote:
> Stephen Kent wrote:
>
> > The Netscape discussion for this extension makes little or no sense
> > to me, based on your description. As Frank notes, this is an
> > extension one expects to see in an EE cert, vs. a CA cert, so one
> > would not encounter multiple ones in validating a path.  If I did use
> > this extension in a CA cert, given the semantics, it might well
> > conflict with an EE usage.  Certainly the keyUasage bits for CA certs
> > and EE certs are distinct, so why would one expect a relationship of
> > the sort described for this extension.
>
> Thank you Stephen for this clear comment.
>
> I can now consider I have a definitive answer on that :-)
>
> In fact, what Netscape describes is the behaviour of Microsoft products
> today, not really it's own, as far as I understand.
>
>