RE: Extended Key Usage and path validation

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

Jean-Marc,

RFC 2459 doesn't say a whole lot about handling extended key usage
extensions. For example, section 6.1 of RFC 2459 contains one instance of
"usage":

"(m) If a key usage extension is marked critical, ensure the keyCertSign bit
is set."

which only makes sense for certificates 1 through n - 1. Note that section
6.1 does include:

"(h)  Recognize and process any other critical extension present in the
certificate."

Extended key usage is commonly included in end-entity certificates to
authorize an end-entity to sign certain things. One example is signing OCSP
responses (see section 4.2.2.2 of RFC 2560).

So one way to look at this issue to:

- check key usage extensions as part of one's general-purpose path
validation
- check extended key usage as part of one's protocol-specific "signature
validation"

In this case, "signature validation" means verifying the signature plus
checking the signer's certificate.

I was unable to find any discussion about extended key usage in RFCs 2312
and 2632. So I am not sure what Netscape is saying about using extended key
usage in S/MIME. I wonder if Netscape's information is outdated.

Frank

> -----Original Message-----
> From: Jean-Marc Desperrier [mailto:jean-marc.desperrier@certplus.com]
> Sent: Thursday, November 02, 2000 2:24 PM
> To: ietf-pkix
> Subject: Extended Key Usage and path validation
> 
> 
> 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).
>