Re: Extended Key Usage and CP extensions (path validation)

["Tom Gindin/Watson/IBM" <tgindin@xxxxxxxxxx>]

     IMHO the CP extension is not a good place for this, since the set of
policy OID's is not standardized and the OID's are not related to those for
EKU.  That leaves us with three basic possibilities, since EKU with its
normal meaning is not very useful in CA certificates:

1    Define EKU as having its current meaning when it appears in an EE
certificate, and as a constraint when it appears in a CA certificate.
Thus, if an EE certificate is issued by a CA certificate with an EKU
extension, it may not have any EKU value not included in the CA
certificate's EKU extension.  This matches your suggestion.

2    Deprecate EKU in CA certificates, and define an EKU constraint
extension.  Either this would be a SET OF (or SEQUENCE OF) OID's, with the
same meaning as in case 1, or it would be defined as a CHOICE between
included and excluded, with included being a SET or SEQUENCE of OID's with
the same meaning as in case 1 and excluded being a SET or SEQUENCE of OID's
which may not appear in the EKU of any EE certificate descended from this
one.

3    Deprecate EKU in CA certificates, and declare that the function is not
really needed.  One argument in favor of this is that there is no way to
constrain a CA from issuing a certificate with most of the KeyUsage flags
either, and NR is as strong a case for delegation constraint as most
currently assigned EKU values.

          Tom Gindin


Jean-Marc Desperrier <jean-marc.desperrier@certplus.com> on 11/10/2000
05:01:06 AM

To:   ietf-pkix <ietf-pkix@imc.org>
cc:
Subject:  Re: Extended Key Usage and CP extensions (path validation)



"David P. Kemp" wrote:

> 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.

They are grayer area than that.
If it were that true, there would be no need for basic constraints, name
constraints,
and policy constraints either.

> 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.

Well, I'm not sure either that EKU serves an useful purpose in a CA
certificate.

We know it's going to be only used to sign certificates, so do we ever
actually need an
EKU for a CA, as is described in the current rfc2459 wording ?

It's different for the EE : For example putting a time-stamping extension
in the EKU is
mandatory in the TSP draft.

I think every CA certificate currently in use that include a EKU extension,
does it with
the intend that it will be interpreted according to the Netscape/Microsoft
misusage, not
the official rfc2459 usage.
If I can be proven otherwise, it invalidates the rest of this message, so
please provide
information about this.

I've been reading the discussion about the CP.

As has been said already
"A rule of thumb might that KU/EKU specifies things which could be be
 wired into a generic toolkit, but CP specifies things which must be
 decided by application-specific code."

Therefore I have the following suggestion :
I wonder if would not be a nice idea to treat the EKU in a way that's more
similar to
the CP extension.

Something like :
In an end-entity certificate, these extended key usages indicate ...
In a CA certificate, these extended key usage limit the set of extended key
usage for
certification paths which include this certificate.

I think this would be simpler that creating a new extension and since this
is already
the mecanims for the CP extension, I don't see the problem in applying it
to the EKU
extension too, especially since this the way the market already treats the
EKU
extension.

Any other solution will be very hard to get accepted by the market, and
will probably
lead to a situation where the rfc says one thing, and the market does
another, or at
least to a very long transition period, so if there's a way to avoid that,
just why not
?