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
