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.
Thanks,
Corey
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
