I agree as well.  I think this proposal has several problems.

First, the text states "if a CA forgets to add keyUsage, the certificate 
usage fails ...."  A more accurate statement would be that if the 
keyUsage extension is absent from the certificate, then no restrictions 
are imposed on the use of the subject public key except.... We cannot 
say that the absence of a keyUsage extension equates to "a CA forgets to 
add keyUsage" and the absence of keyUsage is not a failure.  The problem 
with making a statement about the absence of keyUsage is the "except 
...."  There are a number of things other than keyUsage that could limit 
the acceptable uses of the subject public key:

1) If it is a version 3 certificate and the basicConstraints extension 
is absent or is present with cA=FALSE, then the subject public key 
cannot be used to verify signatures on certificates.  If it is a version 
1 or 2 certificate, the subject public key cannot be used to verify 
signatures on certificates unless it can be verified through out-of-band 
means that the certificate is a CA certificate.

2) A path length constraint imposed by a certificate earlier in the path 
may prevent use of the subject public key for verify signatures on 
certificates.

3) The subject public key cannot be used to verify signatures on CRLs 
(or at least CRLs that will actually be used to determine the status of 
a certificate) unless the subject has been authorized to issue CRLs 
either because the subject is a CA and the CRLs cover its own 
certificates or the subject is issuing indirect CRLs and has been 
delegated that authority through the cRLIssuer field in a certificate 
(section 6.3.3, step (b)(1)). [Note that there is no requirement for the 
basicConstraints extension to be present to use the key to verify 
signatures on CRLs.]

4) The use of the subject public key may be limited by the 
certificatePolicies or extended key usage extensions.

5) The certificate could include a private extension that limits the use 
of the subject public key.


If the keyUsage extension is absent, then it can be used for any 
purpose, even for verifying signatures on certificates and CRLs, unless 
that usage is restricted by some other means as described above.

Section 4.2.1.12 of 3280bis states "If the [extended key usage] 
extension is present, then the certificate MUST only be used  for one of 
the purposes indicated."  There is already text for keyUsage that 
implies that the absence of the extension means no restrictions:

      The key usage extension defines the purpose (e.g., encipherment,
      signature, certificate signing) of the key contained in the
      certificate.  The usage restriction might be employed when a key that
      could be used for more than one operation is to be restricted.

This implies that the keyUsage extension only needs to be present if 
there is a desire to restrict the use of the key and so the absence of 
the extension means the absence of restrictions.  Would people prefer 
for section 4.2.1.3 (Key Usage) to use language closer to the language 
for extended key usage?

Dave

P.S.  Since I have never seen any suggestion of any attempt to add new 
bits to the keyUsage extension, I don't think we need to include a 
warning related to that possibility.  Besides, I would assume that a CA 
that does not include keyUsage really does not intend to limit the usage 
of the key (unless extended key usage or a similar extension were 
included).  I don't think one would leave keyUsage out of the extension 
with the intention being to restrict the usage to the nine usages 
currently specified in the keyUsage extension.

Stefan Santesson wrote:

>Peter, 
>
>I don't like this text based on principles.
>
>An absent extension by itself does not provide any specific information
>at all. 
>
>An absent extension only means that this information, constraints,
>guidance is not present.
>
>In order for any thing "absent" to have a meaning, there must be a
>default definition and in a way I could agree that the default usage for
>a cert is unrestricted. But then again, there are so many other ways to
>restrict the usage, that it is impossible to generally assume a default
>state just considering an absent key usage extension.
>
>There is also difference in what we require a CA to set and what a
>client should accept. Just because a compliant CA must set the cert
>signing key in a CA cert does not mean that my clients can't accept a CA
>cert that has an absent key usage extension (e.g. accepting a V1 CA
>cert).
> 
>  
>
Peter Gutmann wrote:

>Sam Roberts <sroberts@certicom.com> writes:
>
>  
>
>>Also, as you well know, the MUST clauses for certificate generation in PKIX
>>are already widely ignored or misintepreted, and we have to deal with those
>>certs anyhow. Adding more generation MUST clauses won't help us.
>>    
>>
>
>Yeah, fair enough.
>
>  
>
>>Adding text in PKIX that more clearly explains what the bits are for, and
>>what it means for the extension to not be present might be helpful.
>>    
>>
>
>Hmm, I think there should then at least be a note in the security requirements
>about the default allow-all behaviour of keyUsage, e.g.:
>
>  If no keyUsage extension is specified, the certificate is assumed to be
>  valid for any usage except certificate and CRL signing.  In other words if a
>  CA forgets to add the keyUsage, the certificate usage fails open rather than
>  failing closed.  In addition, new and unexpected usages may appear if
>  additional keyUsage bits are defined after the certificate (with its allow-
>  all default) is issued.
>
>That at least warns users/CAs of the consequences of the default allow-all
>behaviour.
>
>Peter.
>