Subject: RE: Extended Key Usage and path validation

From: Frank Balluffi <[email-masked]>
Date: Fri, 03 Nov 2000 06:08:22 -0800

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:[email-masked]]
> 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).
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Nov 2000 18:35:15 -0500

Frank & Jean-marc,

The Netscape discussion for this extension makes little or no sense 
to me, based on your description. As Frank notes, this is an 
extension one expects to see in an EE cert, vs. a CA cert, so one 
would not encounter multiple ones in validating a path.  If I did use 
this extension in a CA cert, given the semantics, it might well 
conflict with an EE usage.  Certainly the keyUasage bits for CA certs 
and EE certs are distinct, so why would one expect a relationship of 
the sort described for this extension.

Steve

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 06 Nov 2000 11:49:51 +0100

> the sort described for this extension.

Thank you Stephen for this clear comment.

I can now consider I have a definitive answer on that :-)

In fact, what Netscape describes is the behaviour of Microsoft products
today, not really it's own, as far as I understand.

---

From: [email-masked] (Terry Hayes)
Date: Tue, 07 Nov 2000 11:30:32 -0800

Netscape's processing of the EKU extension requires that every 
certificate in the chain has a particular EKU value in some cases.  The 
EKU extension is being used as a replacement for an older 
Netscape-defined extension called "Netscape Certificate Type".  This 
extension indicated the types of PKI applications that the certificate 
could be used for, and for CAs indicated whether the CA was allowed to 
issue certificates for that PKI application.  The older extension 
covered SSL (client and server), S/MIME and "object signing" (for secure 
Java applications).

Since the processing of the EKU extension is intended to provide 
information on both the EE (can it participate in this PKI application) 
and the CA (can it issue the certificate), the extension is checked at 
all points in the path.  Except for the trusted anchor all CA 
certificates in the path must have the EKU value corresponding with the 
current usage.  (Actually, CA certificates without and EKU extension are 
"grandfathered" for SSL and S/MIME, but not object signing).  The result 
is effectively the intersection of the EKU values in the path.

That's the current implementation.  I believe that IE does similar 
processing.  I do agree with Stephen Kent that this might be viewed as 
conflicting with the key usage that applies to the CA itself.  That is, 
the presence of an EKU extension value for S/MIME in the CA certificate 
might be interpreted as allowing the CA to use the key for signing 
S/MIME messages, rather than indicating that it can issued S/MIME 
certificates.

In fact, I probably could be convinced that Certificate Policies is the 
correct way of checking the validity of a path for a particular 
purpose.  An application might require that a particular policy value is 
present in a certificate path before S/MIME operations would be allowed 
using that certificate.  X.509 and the various PKIX RFCs already define 
how to validate the policy extension.

The problem with using certificate policy values for this purpose is 
that there is no standard policy OID that is defined to represent S/MIME 
or SSL operations.  In order to encourage wide interoperability of these 
applications, the software must come with certain values preinstalled.  
Most users don't have the understanding necessary or the desire to 
configure their browser or messaging software with PKI configuration 
data.  If policy values are used to control this, a standard value must 
be defined and used by all PKI deployments, to represent basic S/MIME or 
SSL enablement.

We could probably "steal" the OID from the EKU definition, and use it in 
the context of certificate policy.  I don't see any problem with doing 
this; it would cleanly separate the path validation parameters from the 
intended end-use of the key.

Terry Hayes
Netscape Communications Corp.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 08 Nov 2000 12:39:23 +0100

Terry Hayes wrote:

> the extension is checked at all points in the path.  Except for the
> trusted anchor all CA certificates in the path must have the EKU value
> corresponding with the current usage.

> (Actually, CA certificates without and EKU extension are
> "grandfathered" for SSL and S/MIME, but not object signing).

That's not the result of my tests with the current Netscape Navigator
(4.75) and the object signing tools (signtool 1.3).
According to this tests, CA certificates without EKU and NKU extension
are "grandfathered" for object signing too when checking the correct
box.

For the object signing tool, the CA that delivers the signers
certificate must be authorized for object signing, but the check box for
that is available even when there is neither EKU and no NKU in the CA
certificate.

For the navigator, one of the CA in the trust chain must be authorized
for object signing (the box has to be checked).
I've been testing with a signer certificate, an object signing CA, a CA
that signs this CA, and another root CA above all that, therefore three
levels of CAs.

It's impossible to authorize a CA for object signing when the NKU/EKU
are present and don't have the correct usage.