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 <dev-security-policy-boun...@lists.mozilla.org> On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 9:35 AM
To: Jakob Bohm <jb-mozi...@wisemo.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
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 <
dev-security-policy@lists.mozilla.org> 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
correcting.
I thought I was very precise here, so it's useful to understand your
confusion:
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@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
