Subject: Extended Key Usage and path validation

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 02 Nov 2000 20:23:32 +0100

I've been trying recently to understand how path validation should be
done for the usage of a key.

Until now, the only document that I've found that's really explicit is
the following from Netscape/iPlanet :
http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm

Netscape, in this document, says this about extended key usage in path
validation.

"A given certificate is valid only for the intersection of key usages of
all the certificates in the chain to its root (as determined by both the

Extended Key Usage extension for each certificate and the corresponding
user settings). To be valid for a particular usage, the end-entity
certificate and all certificates in the chain must all be valid for that
usage"

In fact, in the context it's not very clear whether this is what
Netscape recommends or the current practice of Microsoft softwares.

But their recommendation for certificat format in table B.1 of that
document is perfectly coherent with that.

This path validation does not apply to keyUsage.
A CA with a keyUsage of keyCertSign, cRLSign, can perfectly emit a valid
certificate with a keyUsage of digitalSignature.

I've been reading through RFC2459, and I was not able able to find
anything that really supports this behaviour.

Is this actually the intended use of key usage and extended key usage ?

For example Netscape recommends the following for a CA that signs S/MIME
client certificate :
extKeyUsage: Email
keyUsage: keyCertSign, cRLSign

But then extKeyUsage and keyUsage are not consistent each other.
After RFC2459, "extKeyUsage: Email" is consistent with digitalSignature,
but not with keyCertSign, cRLSign

RFC2459 says the certificate MUST only be used for a purpose consistant
with both fields and is invalid if none exist.
This only applies when both are flagged critical, but if the correct
setting of this values forbids you to set them critical, it sounds quite
annoying.
There should be an explicit table of what is compatible with what.
I'm afraid not every implementer of RFC2459 will make the same decision
of which values are compatible if trying to implement that with the
current text in RFC2459.txt or draft-ietf-pkix-new-part1-02.txt.

Now if extended key usage must not be used in path validation, then we
loose the possibility to constraint the usage of a certificate in the
CAs above it, except maybe through policy, but this is not something the
software can interpret as easily as extended key usage.

Should this way of using extKeyUsage be considered bad practice and
avoided or not ?

Isn't there the need for a PKIX document that would explicitely detail
how a complex CA path should be set for various uses ? (if there is one
that can effectively be used for that, I've missed it).

---

From: "Shantanu Bhattacharya" <[email-masked]>
Date: Fri, 3 Nov 2000 14:40:43 +0530

In my view, the EKU should not be the intersection for the simple reason
that one PKI vendor might decide his own EKU bit, but his CA's cert is not
self signed and is issued by another PKI vendor who does support that EKU
bit. This case can never be supported if the EKU is used as the intersection
of all EKUs in the cert chain.

Regards

Shantanu Bhattacharya
Project Manager,
E-Lock Technologies Pvt. Ltd,
Opp Symphony Restaurant,
Pune, India.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 03 Nov 2000 12:33:38 +0100

> of all EKUs in the cert chain.

This is the purpose of this mecanism.

A signs the CA of B who decides to create certificate that uses a new EKU bit.

Either A has decided that he doesn't want to restrict B in any way.
He will not put any EKU in B's certificate, and B can use any EKU afterward.

Or A decides that he signs B, but only to emits S/MIME, or SSL certificates and
that he doesn't want B to use his endorsement of the B hierarchy to create
another kind of certificate.

He will put an EKU with S/MIME and SSL, and be sure that B will never be able to
use his certificate to sign anything else.

Now I believe this is not RFC2459 compliant, but it seems to be the behaviour of
some products, and a functionnality people wants (The netscape-cert-type
ssl/obj/emailCA bits had the same usage).