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-pol...@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 <mailto: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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
