Re: Extended Key Usage and path validation

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: thayes@netscape.com (Terry Hayes)
> 
> A CA can put this global OID into the CertificatePolicies along with 
> OIDs for its own more specific or more constrained policies.  The 
> extension can handle more than one OID.
> 
> > [Patrick.Patterson@sita.int]
> > I know the issue here is that we need some technical way to assure that a given
> > certificate isn't used for something that it was not intended for, but I'm not
> > sure that either the current method or your proposed fix is the way it should
> > go. Shouldn't this be something that an attribute certificate be used for, or am
> > I completely off the mark with that?




I agree with Steve Kent that putting an EKU in a CA certificate which does
not apply to the CA's key is a misusage of that extension.

I agree with Patrick Patterson and Michael Ströder that using the
Certificate Policies extension to control usage of the EE key
"messes with" the CP extension.  The policy under which certificates
are issued seems tenuously related, if not completely unrelated,
to the applications which make use of the certificates.

We have basic constraints, name constraints, and policy constraints,
all of which limit the capabilities of lower CAs and EEs.  And PKIX has
defined AIA and SIA private (non-X.509) extensions.  If it really is
necessary for a CA to constrain the usage of an End Entity's key,
shouldn't we be defining a PKIX-private "EKU Constraints" extension to
be placed in CA certificates?

I'm not convinced that EKU serves a useful purpose.  And if EKU itself
is useful, I'm even less convinced that constraining it at the CA
level, whatever the mechanism, is useful.  If you want EKUs, and you
don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
accept the CA.  But if there is a need to use EKU, and to limit it by
CA, then that need should be satisfied with a clean mechanism, not by
bastardizing the CP extension.