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
Cc: Ryan Sleevi ;
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley
Subject: Re: DigiCert-Symantec Announcement
On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen 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 suppo
