Extended Key Usage and path validation

[Jean-Marc Desperrier <[e-mail]>]

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