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 https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations terminology. 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 case. 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
