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.


-----Original Message-----
From: dev-security-policy <> On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 12:53 PM
To: mozilla-dev-security-policy <>
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 

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 

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

dev-security-policy mailing list

Reply via email to