Subject: Absent keyUsage in certificates

From: [email-masked] (Peter Gutmann)
Date: Mon, 30 May 2005 21:04:15 +1200

If anyone from Verisign-called-Thawte is reading this, could you please fix
your certs to include the keyUsage extension?  They're currently being issued
without any keyUsage indication (or at least some of them are), which is
causing some debate about how to apply them (the contact details I have for
someone at Verisign seem to be out of date).

Also, could the current wording around keyUsage in bride-of-3280 be improved
to indicate what the correct usage is if the extension is absent?  Squinting
at the text sideways, it currently says that the key can be used for anything
*except* cert and CRL verification, a rather strange allow-some/deny-some
interpretation when it's more normal to have a default of either allow-all or
deny-all (fail-open/fail-closed) in the absence of any further instructions,
but this is quite hard to see for anyone who doesn't already know in advance
how keyUsage works.  The sentence "Conforming CAs MUST include this extension
in certificates that contain public keys that are used to validate digital
signatures on other public key certificates or CRLs" is particularly obtuse. 

I would suggest adding either:

  Conforming CAs MUST include this extension in all certificates.

(by far the simplest solution, there's no reason not to include this in a
cert, it's at the same level as basicConstraints, and virtually every CA in
existence does it anyway), or at least:

  Where this extension is absent, the certificate may be used for all purposes
  that the public-key algorithm is capable of except certificate and CRL
  signing and validation.
  
Peter.

---

From: Sam Roberts <[email-masked]>
Date: Mon, 30 May 2005 10:24:42 -0400

> deny-all (fail-open/fail-closed) in the absence of any further instructions,

I agree that allow-all or deny-all is sensible, and special-casing two
of the bits would be weird, but isn't allow-all what is specified now?

This interpretation is based on the validation rules, section 6.1.4,
rule (n):

  If a key usage extension is present, verify that the keyCertSign bit
  is set.

I can't see anything that says that absence of Key Usage should trigger
chain validation failure.  Its a long RFC, an you point to the text you
are "squinting sideways" at?

>   Conforming CAs MUST include this extension in all certificates.

Why MUST an end-entity cert include a Key Usage, not including it is a
good way of specifying allow-all. You want to forbid allow-all?

Cheers,
Sam

-- 
http://www.certicom.com

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 31 May 2005 04:30:35 +1200

Sam Roberts <[email-masked]> writes:

>I agree that allow-all or deny-all is sensible, and special-casing two of the
>bits would be weird, but isn't allow-all what is specified now?

Nope.  See below.

>This interpretation is based on the validation rules, section 6.1.4, rule
>(n):
>

Oh, section 6 contradicts section 4 in a number of places, I take section 4 as
definitive since it specifies the intent of the spec whereas section 6 only
contains an attempt at implementing that intent.

(Another proposed improvement for bride-of-3280, indicate which of section 4
 or 6 is definitive in the case of conflict).

>I can't see anything that says that absence of Key Usage should trigger chain
>validation failure.

The exact text I quoted earlier, i.e:

  Conforming CAs MUST include this extension in certificates that contain
  public keys that are used to validate digital signatures on other public key
  certificates or CRLs.

>Its a long RFC, an you point to the text you are "squinting sideways" at?

The keyUsage text, which covers the use of keyUsage in a very obtuse way.
What the above is trying to say in a very roundabout way is:

  CA certificates must include a keyUsage extension with keyCertSign or
  crlSign bits set as appropriate.

>Why MUST an end-entity cert include a Key Usage, not including it is a good
>way of specifying allow-all. You want to forbid allow-all?

No, I want to make it explicit.  As your message shows, at least one PKIX
member (not to mention an unknown but significant number of non-PKIX people)
find the current text/usage quite confusing :-).  Since virtually all CAs
already include keyUsage, explicitly requiring it would fix the problem at
virtually zero cost to implementors.

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 31 May 2005 09:48:15 -0400

Peter,

This seems to be an issue that has caused confusion for several people, 
as Sam Roberts pointed out to me in another forum 
(http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html).

When the keyUsage extension is absent, then the key can be used for any 
purpose (except as restricted by the basicConstraints, extendedKeyUsage, 
certificatePolicies, etc. extensions as Stefan mentioned).

The text that you quoted was intentionally written as "Conforming CAs 
MUST ..." because it is a requirement that ONLY applies to CAs.  So, 
section 4 and 6 are not contradictory.  The text from section 4 that you 
quoted imposes a requirement on CAs, but does not apply to relying 
parties.  The text that Sam quoted from section 6 is part of the path 
validation algorithm, which is used by relying parties but not CAs.

The basic idea is that while the PKIX Certificate and CRL profile (RFC 
3280, 3280bis) imposes stricter certificate and CRL generation 
requirements than X.509 does, there is no requirement to reject a 
certification path that is valid under X.509 simply because it was not 
issued in conformance with the PKIX profile.  While it would be nice if 
every CA followed the PKIX profile of X.509, I don't think PKIX should 
mandate that certificates be rejected simply because they were issued in 
accordance with a profile of X.509 that does not conform to the PKIX 
profile.  This is the reason that the path validation algorithm in RFC 
3280 and 3280bis was designed to accept any certification path that is 
valid under X.509 and it does not include checks to verify that 
certificates were issued in conformance to the PKIX profile.  So, even 
if PKIX required all certificates to include a keyUsage extension, this 
could only be a requirement for conforming CAs, not relying parties.

Sam suggested that I add text to section 6 of 3280bis clearly stating 
that the PKIX path validation algorithm is designed to accept any 
certification path that is valid under X.509, not just those that were 
issued in conformance with the PKIX profile.  He made the suggestion a 
few days after the -00 draft was originally submitted, but I intend to 
include this text in the -01 draft.

As to your question about whether section 4 takes precedence over 
section 6 or vice versa, I don't think there is a real answer.  In 
general, section 6 provides the definitive explanation of how to perform 
certification path validation.  However, section 6 does not repeat all 
of the details from section 4.  For example, section 6.1.3 steps (b) and 
(c) and section 6.1.4 step (g) discuss the processing of name 
constraints, but one must read section 4.2.1.10 to understand the rules 
for applying name constraints to each name form.  On the other hand, 
while section 4.2.1.11 provides a good textual description of the 
policyConstraints extension, this section does not provide enough detail 
to implement the path validation algorithm.  So, if you want a general 
understanding of the extension, read section 4.  If you want to 
implement the code to process the extension, read section 6.

BTW, if there are places where section 6 contradicts section 4, please 
point them out so that they can be fixed.  But remember that the 
algorithm in section 6 was not intended to verify that CAs issued 
certificates and CRLs in conformance with section 4.  So, if there is a 
requirement in section 4 of the form "conforming CAs MUST ...", there 
may not be a corresponding requirement imposed in relying parties.

Dave

Peter Gutmann wrote:

>> agree that allow-all or deny-all is sensible, and special-casing two 
>> of the

---

From: Steve Hanna <[email-masked]>
Date: Tue, 31 May 2005 10:30:37 -0400

This is a good example of Jon Postel's advice:

Be liberal in what you accept, and conservative in what you send.

CAs should set keyUsage but relying parties
should not require it to be set (unless
explicitly configured to do so).

Of course, there must be limits to an RP's
"liberalism". An RP should not accept a purported
CA certificate that contains a keyUsage extension
that doesn't have the keyCertSign bit set.

Thanks,

Steve

David A. Cooper wrote:
>>> rule