Re: Absent keyUsage in certificates

[Sam Roberts <sroberts@xxxxxxxxxxxx>]

Wrote Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx>, on Mon, May 30, 2005 at 09:04:15PM +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,

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?

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

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