Confirmed users, Administrators
5,526
edits
CA/CertificatePolicyV2.1: Difference between revisions
Jump to navigation
Jump to search
→Frequently Asked Questions
| Line 15: | Line 15: | ||
# RFC 5280 reads "In general, this extension will appear only in end entity certificates". Is it non-standard to have EKU in intermediate certificates, and will client software break when receiving such a certificate chain? | # RFC 5280 reads "In general, this extension will appear only in end entity certificates". Is it non-standard to have EKU in intermediate certificates, and will client software break when receiving such a certificate chain? | ||
#* 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 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, other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType | #* 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. | |||