On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <k...@kuix.de> wrote:

> Hello Ryan,
> thanks a lot for your very helpfull response!
> A couple more comments below:
> On 12.02.2018 19:13, Ryan Sleevi wrote:
> >     A separate question which would be good to clarified: What about
> >     environments, which want to distrust all old Symantec roots in
> October
> >     2018, but cannot add whitelisting to their cert validation code, and
> >     choose to explicitly trust each of the subCAs. Such an environment
> >     should be able to find a chain to one of the explicitly trusted
> subCAs,
> >     right?
> >
> > You're asking about non-browser environments that cannot
> > implemented https://wiki.mozilla.org/CA:FAQ#Can_I_use_
> Mozilla.27s_set_of_CA_certificates.3F
> > ? I thought we'd ruled that out of scope rather comprehensively.
> Do you mean out of scope for this discussion on this list? I understand.

Not out of scope of discussion - I think it's good to have that discussion.
Personally, I view it more as a Tier-1 vs Tier-3 conversation, but I
realize others may see it as Tier-1 vs Tier-2, to use the

As it relates to the question you posed, I don't think we can reason about
the abstract "environments", but if there's a concrete environment you
maintain and can speak to, I think it's good to have that conversation.

Put differently yet again, I suppose I took the framing of the question as
"What if this change breaks platforms that don't have 8-bit bytes", and I'd
push back and say "If they're not here and able to engage, then so what".
If the question is "I support DEC-10 and this will break me", then I'm more
inclined to say "Let's try and find a solution that works, if you can speak
to your constraints and help debug, but this won't necessarily be a blocker
to landing"

Does that make it more palatable? :)

I wonder if we should have a separate mailing list, where secondary
> consumers of the Mozilla CA list could exchange thoughts on how to
> implement the changes intended by Mozilla as closely as possible.
> >     > We've already seen this born out
> >     > with respect to DigiCert and their Managed PKI intermediates, and
> wanted
> >     > to avoid disruption to both Apple and Google that would otherwise
> >     > destablize the ecosystem.
> >
> >     What is the relationship between the distrust of Symantec CAs and
> >     intermediates managed by DigiCert? Did DigiCert already run managed
> >     intermediates, before the Symantec-to-DigiCert migration efforts
> begun,
> >     that still depend on Symantec CAs to be trusted?
> >
> > I'm not sure I understand this question?
> I was trying to understand the origin of the additional subCAs, which
> need to be covered using transitional intermediates. Who created those
> managed CAs initially, and why are they related to the Symantec to
> DigiCert transition? If they were originall issued by Symantec Root CAs,
> why weren't they included in the initial list of subCAs that need to be
> excluded?

I'm still having trouble understanding your question.

There are two organizations operating externally-operated sub-CAs (e.g.
fully independent infrastructure, independently audited). That's Apple and
Google. They each have several certificates underneath the GeoTrust
hierarchy, and Apple at least has several keys as well. These are
organizations that, looking at a long-term view, should transition off
GeoTrust, just like every other Symantec customer should do. Yet they're
also organizations that are, for all available information, fully isolated
and independent from every known issue - that is, unlike server
operators/existing customers, none of their certificates are suspect due to
the issues.

Now, for various reasons, Symantec operated some of these CAs as requiring
annual renewal/review, based on contractual obligations. Solutions that
prevent that, in effect, are equivalent to distrusting those independent
operators - by preventing new certs. Both of these organizations have
substantial dependence on the GeoTrust root, although for different
reasons, and while both organizations are in the process of transitioning
those dependencies away, we don't want to create a situation where this
transition is suddenly interrupted. Is this ideal? No. Could this happen
with any other sub-CA operation? Unfortunately. Do we want to guarantee
this is how all future situations will be handled? Not necessarily.
However, it happened that the audits are comprehensive enough, and the risk
significant enough, to require consideration of these events. A whitelist
of SPKI doesn't allow new keys to be introduced (not ideal from risk
management), but does allow new certs to be issued to assist that
transition (if necessary).

Separate from this, DigiCert was selected as the Managed Partner
Infrastructure for Symantec. Setting aside the acquisition of Symantec's
PKI business, DigiCert is running sub-CAs underneath Symantec roots, to
issue certificates for customers to enable them to make a smooth and
orderly transition to other CAs - including DigiCert's own roots. The keys
were created by DigiCert (as per the Managed Partner Infrastructure plan),
while the certificates were signed by "Symantec" (ignoring, again, that it
was DigiCert-operating-Symantec's-PKI signing
DigiCert-as-Symantec's-Managed-Partner). It was expected (and has been
borne out) that not all of the necessary transitional paths would be
identified - despite significant discussion trying to find those paths. The
whitelist by SPKI allows the flexibility that, as additional transitional
paths and compatibility issues are discovered, new certificates (with new
DNs) can be identified and cut, to aid in those transitional paths.

Are these necessary for the Firefox or Chrome case, or more generally, the
browser case? Not as much, because in the browser case, you know what the
root set is, you know what the transitional paths are, generally speaking.
It largely matters for pinning, at least from the browser functionality

Are they necessary for a "system" root store to consider, or more
abstractly, "systems" of root stores? Yes. That's why I'm saying it's risky
to bake it in for something like a list.

Further, if/as those paths have to be explored to support legacy systems,
you don't want the browser to choke on those, because then you're again
forcing it into the "either break in the browser, or break in the system" -
which is precisely the problem we're trying to mitigate. If we didn't care
about breaking those systems, baking in a DN whitelist, or even baking in
the cert themselves, would be fine. But the Managed Partner Infrastructure
transition plan was designed to find a way to meet browsers' security needs
*without* breaking those legacy systems, which is why a browser solution
that can lead to either/or choices is not ideal.

Does that make more sense?
dev-security-policy mailing list

Reply via email to