[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Absent keyUsage in certificates



I'm not sure I get the problem or what has to be fixed.

This extension defines the use of the public key in the certificate. So
obviously, in absence of this extension the usage is simply undefined in
the context of this extension.

The use of the public key may however still be constrained by other
means, such as certificate policy, EKU, Basic Constraints etc. So it is
not correct to define that absent key usage extension = all usages. 

The key usage extension is already required for CA certs.

/Stefan
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Peter Gutmann
> Sent: den 30 maj 2005 18:31
> To: ietf-pkix@xxxxxxx; sroberts@xxxxxxxxxxxx
> Subject: Re: Absent keyUsage in certificates
> 
> 
> 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.