Peter,This seems to be an issue that has caused confusion for several people, as Sam Roberts pointed out to me in another forum (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html).
When the keyUsage extension is absent, then the key can be used for any purpose (except as restricted by the basicConstraints, extendedKeyUsage, certificatePolicies, etc. extensions as Stefan mentioned).
The text that you quoted was intentionally written as "Conforming CAs MUST ..." because it is a requirement that ONLY applies to CAs. So, section 4 and 6 are not contradictory. The text from section 4 that you quoted imposes a requirement on CAs, but does not apply to relying parties. The text that Sam quoted from section 6 is part of the path validation algorithm, which is used by relying parties but not CAs.
The basic idea is that while the PKIX Certificate and CRL profile (RFC 3280, 3280bis) imposes stricter certificate and CRL generation requirements than X.509 does, there is no requirement to reject a certification path that is valid under X.509 simply because it was not issued in conformance with the PKIX profile. While it would be nice if every CA followed the PKIX profile of X.509, I don't think PKIX should mandate that certificates be rejected simply because they were issued in accordance with a profile of X.509 that does not conform to the PKIX profile. This is the reason that the path validation algorithm in RFC 3280 and 3280bis was designed to accept any certification path that is valid under X.509 and it does not include checks to verify that certificates were issued in conformance to the PKIX profile. So, even if PKIX required all certificates to include a keyUsage extension, this could only be a requirement for conforming CAs, not relying parties.
Sam suggested that I add text to section 6 of 3280bis clearly stating that the PKIX path validation algorithm is designed to accept any certification path that is valid under X.509, not just those that were issued in conformance with the PKIX profile. He made the suggestion a few days after the -00 draft was originally submitted, but I intend to include this text in the -01 draft.
As to your question about whether section 4 takes precedence over section 6 or vice versa, I don't think there is a real answer. In general, section 6 provides the definitive explanation of how to perform certification path validation. However, section 6 does not repeat all of the details from section 4. For example, section 6.1.3 steps (b) and (c) and section 6.1.4 step (g) discuss the processing of name constraints, but one must read section 4.2.1.10 to understand the rules for applying name constraints to each name form. On the other hand, while section 4.2.1.11 provides a good textual description of the policyConstraints extension, this section does not provide enough detail to implement the path validation algorithm. So, if you want a general understanding of the extension, read section 4. If you want to implement the code to process the extension, read section 6.
BTW, if there are places where section 6 contradicts section 4, please point them out so that they can be fixed. But remember that the algorithm in section 6 was not intended to verify that CAs issued certificates and CRLs in conformance with section 4. So, if there is a requirement in section 4 of the form "conforming CAs MUST ...", there may not be a corresponding requirement imposed in relying parties.
Dave Peter Gutmann wrote:
Sam Roberts <sroberts@xxxxxxxxxxxx> writes:agree that allow-all or deny-all is sensible, and special-casing two of thebits 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 onlycontains an attempt at implementing that intent.(Another proposed improvement for bride-of-3280, indicate which of section 4or 6 is definitive in the case of conflict).I can't see anything that says that absence of Key Usage should trigger chainvalidation failure.The exact text I quoted earlier, i.e: Conforming CAs MUST include this extension in certificates that containpublic keys that are used to validate digital signatures on other public keycertificates 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 goodway of specifying allow-all. You want to forbid allow-all?No, I want to make it explicit. As your message shows, at least one PKIXmember (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.