Interesting. I can't tell with the Netlock certificate, but the other three non-EKU intermediates look like replacements for intermediates that were issued before the policy date and then reissued after the compliance date. The industry has established that renewal and new issuance are identical (source?), but we know some CAs treat these as different instances. While that's not an excuse, I can see why a CA could have issues with a renewal compared to new issuance as changing the profile may break the underlying CA.
Note that revoking these CAs puts the CA back on issuing from the legacy ICA that was issued before the renewal. Depending on the reason for the reissue, that may be a less desirable outcome. I don't have a good answer on what to do in a circumstance like this (and I'm a bit biased probably since we have a relationship with Quovadis). However, there's probably something better than "trust" vs. "distrust" or "revoke" v "non-revoke", especially when it comes to an intermediate. I guess the question is what is the primary goal for Mozilla? Protect users? Enforce compliance? They are not mutually exclusive objectives of course, but the primary drive may influence how to treat issuing CA non-compliance vs. end-entity compliance. Of the four, only Quovadis has responded to the incident with real information, and none of them have filed the required format or given sufficient information. Is it too early to say what happens before there is more information about what went wrong? Key ceremonies are, unfortunately, very manual beasts. You can automate a lot of it with scripting tools, but the process of taking a key out, performing a ceremony, and putting things a way is not automated due to the off-line root and FIPS 140-3 requirements. BTW, I'm really liking how these issues are raised here in bulk by problem. This is a really nice format and gets the community involved in looking at what to do. I think it also helps identify common causes of problems. Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Monday, October 7, 2019 12:53 PM To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Mozilla Policy Requirements CA Incidents In light of Wayne's many planned updates as part of version 2.7 of the Mozilla Root Store Policy, and prompted by some folks looking at adding linters, I recently went through and spot-checked some of the Mozilla Policy-specific requirements to see how well CAs are doing at following these. I discovered five issues, below: # Intermediates that do not comply with the EKU requirements In September 2018 [1], Mozilla sent a CA Communications reminding CAs about the changes in Policy 2.6.1. One specific change, called to attention in ACTION 3, required the presence of EKUs for intermediates, and the separation of e-mail and SSL/TLS from the intermediates. This requirement, while new to Mozilla Policy, was not new to publicly trusted CAs, as it matched an existing requirement from Microsoft's Root Program [2]. This requirement was first introduced by Microsoft in July 2015, with their Version 2.0 of their own policy. It's a reasonable expectation to expect that all CAs in both Microsoft and Mozilla's program would have been conforming to the stricter requirement of Microsoft, which goes above-and-beyond the Baseline Requirements. However, Mozilla still allowed a grandfathering in of existing intermediates, setting the new requirement for their policy at 2019-01-01. Mozilla also set forth certain exclusions to account for cross-signing. Despite that, four CAs have violated this requirement in 2019: * Microsoft: https://bugzilla.mozilla.org/show_bug.cgi?id=1586847 * Actalis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586787 * QuoVadis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586792 * NetLock: https://bugzilla.mozilla.org/show_bug.cgi?id=1586795 # Authority Key Identifier issues RFC 5280, Section 4.2.1.1 [3], defines the Authority Key Identifier extension. Within RFC 5280, it states that (emphasis added) The identification MAY be based on ***either*** the key identifier (the subject key identifier in the issuer's certificate) ***or*** the issuer name and serial number. That is, it provides an either/or requirement for this field. Despite this not being captured in the updated ASN.1 module defined in RFC 5912 [4], Mozilla Root Store Policy has, since Version 1.0 [5], included a requirement that CAs MUST NOT issue certificates that have (emphasis added) "incorrect extensions (e.g., SSL certificates that exclude SSL usage, or ***authority key IDs that include both the key ID and the issuer's issuer name and serial number)***;" In examining issuance, I found that one CA, trusted by Mozilla, regularly violates this requirement: * Camerfirma: https://bugzilla.mozilla.org/show_bug.cgi?id=1586860 # Thoughts While I've opened CA incident issues for all five incidents, I am concerned that requirements that have been clearly communicated, and reiterated, are violated like this. The one exception to this is Microsoft, which at the time of issuance was not yet a participant in the Mozilla Root CA Program directly, although admittedly, it's concerning that they might have violated their own Root Program requirements. I'm not sure how we can better prevent such situations, especially when they were clearly communicated and affirmatively acknowledged by the CAs in question. I'd be concerned with any suggestions that only rules placed in the Baseline Requirements should be followed; that would quite literally be placing the cart before the horse, since browsers lead the BRs. I'd love to understand people's thoughts about how to handle such situations, and more generally, what can be done to better prevent such situations going forward. [1] https://wiki.mozilla.org/CA/Communications#September_2018_CA_Communication [2] https://aka.ms/rootcert 4.A.10 [3] https://tools.ietf.org/html/rfc5280#section-4.2.1.1 [4] https://tools.ietf.org/html/rfc5912 [5] https://wiki.mozilla.org/CA:CertificatePolicyV1.0 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
