CA/CertificatePolicyV2.1: Difference between revisions

#* Inclusion of EKU in CA certificates is generally allowed. NSS and CryptoAPI both treat the EKU extension in intermediate certificates as a constraint on the permitted EKU OIDs in end-entity certificates. Browsers and certificate client software have been using EKU in intermediate certificates, and it has been common for enterprise subordinate CAs in Windows environments to use EKU in their intermediate certificates to constrain certificate issuance. Therefore, it is unlikely that using EKU in intermediate certificates would break other client software.

#* The use of the EKU extension in intermediate certificates was discussed at length in the [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0jnELviAxxo mozilla.dev.security.policy forum.] We considered other options, such as standardizing a set of Policy OIDs or un-deprecating NetscapeCertType. The discussion included the concern that one interpretation of RFC 5280 is that this use of EKU is non-standard, but it was decided that the RFCs are not clear, and perhaps conflicting, in regards to EKUs in CA certificates. In the discussion it was pointed out that other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType; and we also recognized the difficulties involved in standardizing a set of Policy OIDs. The conclusion of the discussion was that EKU is the best tool for technically constraining the types of certificates that an intermediate certificate may sign.