Are both roots trusted in the Mozilla root store? If so, could you say that 
Mozilla has approved of the root not-withstanding the non-compliance? If root 2 
did go through the public review process and had the public look at the 
certificate and still got embedded, then Mozilla perhaps signed off on the root.

That said, I don't personally see the harm in incident reports (other than the 
fact that they can be used for negative marketing). They are there for 
documenting issues and making the public aware of issues. Like qualified 
audits, they don't necessarily mean something terrible since they represent a 
disclosure/record of some kind. Even if the incident report is open, discussed, 
and closed pretty quickly, then you end up with an a record that can be pointed 
to.  Filing more incident report (as long as they are different issues) is a 
good thing as it gives extra transparency in the CA's operations that is easily 
discoverable and catalogable. Makes data analytics easier and you can go back 
through the incidents to see how things are changing with the CA.  

-----Original Message-----
From: dev-security-policy <> On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 9:35 AM
To: Jakob Bohm <>
Cc: mozilla-dev-security-policy <>
Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy <> wrote:

> On 07/10/2019 16:52, Ryan Sleevi wrote:
> > I'm curious how folks feel about the following practice:
> >
> > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). 
> > They create this Root Certificate after the effective date of the 
> > Baseline Requirements, but prior to Root Programs consistently 
> > requiring
> compliance
> > with the Baseline Requirements (i.e. between 2012 and 2014). This 
> > Root Certificate does not comply with the BRs' rules on Subject: 
> > namely, it omits the Country field.
> Clarification needed: Does it omit Country from the DN of the root 1 
> itself, from the DN of intermediary CA certs and/or from the DN of End 
> Entity certs?

It's as I stated: The Subject of the Root Certificate omits the Country field.

> >
> > Later, in 2019, Foo takes their existing Root Certificate ("Root 
> > 2"), included within Mozilla products, and cross-signs the Subject. 
> > This now creates a cross-signed certificate, "Root 1 signed-by Root 
> > 2", which has
> a
> > Subject field that does not comport with the Baseline Requirements.
> Nit: Signs the Subject => Signs Root 1

Perhaps it would be helpful if you were clearer about what you believe you were 

I thought I was very precise here, so it's useful to understand your

Root 2, a root included in Mozilla products, cross-signs Root 1, a root which 
omits the Country field from the Subject.

This creates a certificate, whose issuer is Root 2 (a Root included in Mozilla 
Products), and whose Subject is Root 1. The Subject of Root 1 does not meet the 
BRs requirements on Subjects for intermediate/root
certificates: namely, the certificate issued by Root 2 omits the C, because 
Root 1 omits the C.
dev-security-policy mailing list

dev-security-policy mailing list

Reply via email to