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

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:
* Actalis:
* QuoVadis:
* NetLock:

# Authority Key Identifier issues

RFC 5280, Section [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:

# 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.

[2] 4.A.10
dev-security-policy mailing list

Reply via email to