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?
DaveP.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 informationat 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@xxxxxxxxxxxx> 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.