On Monday, October 7, 2019 at 10:52:36 AM UTC-4, 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.
> 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.
> To me, this seems like a clear-cut violation of the Baseline Requirements,
> and "Foo" could have pursued an alternative hierarchy to avoid needing to
> cross-sign. However, I thought it interesting to solicit others' feedback
> on this situation, before opening the CA incident for Foo.

It appears there was a few months’ time in between versions 1.0 and 1.1 of the 
BRs that apparently allowed for omitting the C RDN even if the O was included 
in the Subject. Having spent some time in Censys.io, it appears that this root 
in question was not issued during this period so the root certificate in 
question was mis-issued. However, I think there’s an additional issue that’s 
worth discussing along with the current topic: how to treat cross-signs for 
roots that, when originally issued, were compliant with the BRs and Mozilla 
Policy but now can no longer have their subjectDN embedded in cross-signs due 
to changes in policy.

Given that there is discussion about mandating the use of ISO3166 or other 
databases for location information, the profile of the subjectDN may change 
such that future cross-signs cannot be done without running afoul of policy.

With this issue and Ryan’s scenario in mind, I think there may need to be some 
sort of grandfathering allowed for roots so that cross-signs can be issued 
without running afoul of policy. What I’m less certain on, is to what extent 
this grandfathering clause would allow for non-compliance of the current 
policies, as that is a very slippery slope and hinders progress in creating a 
saner webPKI certificate profile. For the CA that Ryan brings up, I’m less 
inclined to allow for a “grandfathering” as the root certificate in question 
was originally mis-issued. But for a root certificate that was issued in 
compliance with the policy at the time but now no longer has a compliant 
subjectDN, perhaps a carve-out in Mozilla Policy to allow for a cross-sign 
(using the now non-compliant subjectDN) is warranted.

dev-security-policy mailing list

Reply via email to