Re: Absent keyUsage in certificates

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Sam Roberts <sroberts@xxxxxxxxxxxx> 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):
>
>  If a key usage extension is present, verify that the keyCertSign bit
>  is set.

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.