Jeremy, I think the grouping may mix a bit of the solutions in with the problem definitions, so I tried to reword a little. Does this capture the mix of what’s been discussed?
1) Clients that support a ‘common’ root store of various CAs, including DigiCert, and do not use pinning. 2) Browser clients that support a ‘common’ root store of various CAs, including DigiCert, but have exclusively pinned to Symantec legacy roots. 3) Non-browser clients (e.g. native applications) that support a ‘common’ root store of various CAs, including DigiCert, but have exclusively pinned to Symantec roots. 4) Non-browser clients (e.g. native applications, payment terminals) that only support Symantec legacy roots. 5) Browser clients that support a ‘common’ root store of various CAs, including DigiCert, but have exclusively pinned to Symantec legacy intermediates. Sites that exclusively serve clients in Case 1 can migrate to DigiCert’s existing roots, or to any other supported CA, without any disruption. Sites that serve clients in Cases 2 - 4 would all be met by the “Managed CA” case I gave you. Cases 2 and 3 would encounter compatibility problems with path-building if you sign DigiCert roots. Sites that serve clients in Case 5 do not have an readily identified solution that meets the security objectives. Browsers can take steps here, but there's not something from the path building side. This is why I advocate for sticking to the original “Managed CA” plan outlined, as this minimizes the compatibility risk isolated. It also separates out the transition to a “Managed CA,” scheduled for Dec 1, and any other transitions between Symantec and DigiCert, such as the intent to acquire Symantec’s assets. On Sun, Oct 1, 2017 at 12:54 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > Is this a correct summary? > > > > There’s four categories of customers that require trust in existing > Symantec roots being address: > > 1. Those that can migrate to a new trusted root because they use the > certs in a standard TLS-configuration > 2. Those that require a certain Symantec root for various applications > but can use a DigiCert root for standard browser-based TLS > 3. Those that require a non-trusted intermediate because they have > pinned a Symantec root in the application and using a trusted DigiCert > root, even if cross-signed would cause the application to fail. > 4. Those that pinned a specific intermediate’s keys, resulting in a > failure unless the issuing CA had the same keys as used by Symantec. > > > > Category 1 customers are straight-forward. They will be migrated to a > DigiCert root. > > > > Category 2 customers are potentially straight forward but could have > validation issues. If we cross-sign the DigiCert global root with the > required Symantec root, then the customer can migrate but might experience > issues when the root is actually removed. However, this could cause issues > for the 84 certificates already using the DigiCert root. > > > > Category 3 customers are potentially straight forward but will lose trust > in Sep 2018 unless the new root is embedded prior to that date. If we > create a new root, sign it with the Symantec roots, and embed the new roots > as necessary, we avoid the problems with a previously trusted root. > Wouldn’t this have the same validation issues as Category 2? > > > > Category 4 is under discussion. Sounds like Google would prefer not to > see a reuse of keys. Pinning times are sufficiently short that customers > could migrate to the new infrastructure prior to total distrust of the > roots under certain circumstances. If the cert was issued prior to June > 2016, and the key expires after March 2018, anyone using the pin could be > locked out until the pin expires. If pins last up to a year, customers > issuing a cert after June 2016 should have time to migrate prior to root > removal. One issue is that these customers won’t be able to get a new cert > that functions off the old intermediate post Dec 1, 2017, effectively > meaning key compromises cannot be addressed. > > > > = > > Jeremy > > > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Monday, September 25, 2017 8:18 PM > *To:* Peter Bowen <pzbo...@gmail.com> > *Cc:* Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-policy@ > lists.mozilla.org; Jeremy Rowley <jeremy.row...@digicert.com> > *Subject:* Re: DigiCert-Symantec Announcement > > > > > > > > On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen <pzbo...@gmail.com> wrote: > > I agree that 3b potentially has a higher risk than 3z, but it has a > higher reward. 3b allows pins to continue to work even if the trust > store removes 3. It comes down to the level of protection of the root > key. If it is secure, then this provides continued compatibility > while removing the original root. The 3z option means that all pins > to the existing root break. > > This isn't really a risk for browser-based applications, after all the > browser can implement a "known bad pins" list and not enforce pinning > if all the pins are on that list or can choose to not enforce pins if > older than a certain date. However in a situation where the > application is distinct from the browser, this does not work. I > realize this isn't Mozilla (or Chrome's) problem, but it is important > to consider in the broader Internet PKI view. > > Thanks, > Peter > > > > Peter, > > > > Thanks for confirming that this isn’t a concern for browser-based > applications. While not to suggest they are the only participant that > matters in the Web PKI, I think it would be fair to say that many of the > concessions and workarounds have been heretofore focused on the > browser-based case. > > > > That said, I’m not sure it’s as dire as you suspect. As noted in the > previous message, an adoption of 3z wouldn’t break applications pinned to 3 > unless and until a root store took steps to remove. We’ve seen some > platforms, such as macOS and iOS, take steps for manual whitelisting of > pre-existing certs. We’ve seen other platforms, such as Windows, take steps > based on timestamping or date issued. Most importantly, however, the only > public discussions regarding removal have suggested a timeframe of > late-2018. Applications that pinned certificates, without the ability to > update in a year, are arguably outside of the scope of ‘reasonable’ use > cases - the ecosystem itself has shown itself to change on at least that > frequency. > > > > As such, hopefully it’s persuasive that the reward for 3b compared to 3z > is not actually significant, especially for browsers, and the risk is > arguably much greater. Repeating the pattern of 2z & 3z, for every root > with active issuance, provides the greatest way to reduce risk for > applications that have pinned and need additional migration time. Note that > the plan would still suggest that all users should be moved to > DigiCert-by-default, should the Symantec deal close, and 2z/3z used merely > to support those cases that can concretely identify compatibility issues > and need additional time to migrate. Should the Symantec/DigiCert deal fail > to close, then 2z/3z, operated by DigiCert as a Managed CA, can serve to > support those users who cannot migrate to other CAs/PKIs and have the > critical compatibility dependency. > > > > If 3z is adopted, both sites and applications would have until late-2018 > to update their pinning code, and potentially have (depending on use cases > identified) as much as several years to identify and mitigate the > interoperability concerns between ‘truly legacy’ (but not pinned) devices > and actively-maintained clients, while the risk to users from the legacy > infrastructure will be eliminated by the end of 2018. > > > > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
