On Thu, Feb 15, 2018 at 9:37 AM, Kai Engert via dev-security-policy <
> What does that mean for non-browser SSL/TLS client software, which
> cannot do whitelisting based on SPKI, but which wants to ensure
> compatibility with non-migrated certificates?
There are, effectively, two migrations at play.
The Managed Partner Infrastructure plan was designed around a first
migration, which was a migration from Symantec's Legacy Infrastructure onto
that of Managed Sub-CAs. The intent of the design, and as attempted to be
publicly communicated as best possible, was that existing Symantec trusted
roots would have a Managed Sub-CA created under each one (as/if necessary).
As part of the distrust, existing Symantec customers would be able to
freely choose any publicly trusted CA as a replacement CA. If they had
systemic need for trust to chain to Symantec's roots (for example, due to
supporting legacy devices), they could obtain certificates from that
Managed Partner Infrastructure. Similarly, if they had systems that were
integrated with Symantec's issuance systems, and those transitions required
time, the transition to the Managed Partner Infrastructure could allow for
uninterrupted issuance during the phased distrust, providing those
customers time to re-examine their issuance integration, potentially
looking at standards-based approaches (such as ACME) that would provide
greater flexibility and choice in CAs in the future.
This is the first migration - from Symantec issuance to the Managed Partner
Following the announcement and finalization of that plan, Symantec
announced they were selling their PKI business to DigiCert/Thoma Bravo.
This transitioned control of the Legacy Infrastructure (which was to be
distrusted) to DigiCert, who also happened to be the operator of the
Managed Partner Infrastructure.
As part of this transition, DigiCert integrated Symantec's legacy APIs to
support cases where issuance was directed to DigiCert roots, rather than
the Managed Partner Infrastructure, or to the Managed Partner
Infrastructure itself. Further, while it was repeatedly highlighted as
unadvisable, they also cross-signed existing DigiCert roots with Legacy
Symantec Roots, allowing new, nominally DigiCert certificates, to chain
either to existing DigiCert roots or, for systems that did not support
them, to a limited number of Symantec roots.
This is the second migration - from Symantec issuance to DigiCert-chaining
Not all customers' software support the second migration - for example,
cross-signing with multiple roots is a very risky (for compatibility)
option, and so the DigiCert-roots-cross-signed-by-Symantec only go to one
Symantec root each, effectively. When they support a single root that
hasn't cross-signed DigiCert, such as "VeriSign Universal Root
Certification Authority", they can instead leverage the first migration -
the Managed Partner Infrastructure - to maintain support.
Further, not all customers' software supports the first migration - for
example, some embedded software may have assumptions about the length of
the chain or the issuing intermediate embedded within the software. This
was a poor design choice on the device manufacturer/software manufacturers
support, but this reality exists. So some customers find it necessary to
opt out of the migration entirely. If you look at crt.sh for issuance
underneath the Legacy Symantec Infrastructure, you can see entities like
AT&T, TD Bank, VIP providers, and others using it. One can presume this is
to support things such as desktop phones and payment terminals, which
Symantec had raised in the past as part of their customer base.
So what does that mean for non-browser client software? It depends.
If your client software has to support and interoperate with the same
endpoints being used for those ultra-legacy devices (phones and payment
terminals), then that software still needs to trust the Legacy Symantec
Infrastructure. Those operating such endpoints should work to try and
extricate the endpoints, such that there are two endpoints, for 'modern'
and 'legacy', at a minimum. A better design is to ensure that when working
with partner devices that may not be updatable, a unique
hostname-per-device is given (e.g. foo-device.example.com
, where Foo and Bar are different device
manufacturers), to ensure that future trust migrations can be done in a
more calculated way.
If your client software has to support and interoperate with endpoints that
are using the Managed Partner Infrastructure (those that chain to Symantec
roots, but operated by DigiCert, and do not chain to DigiCert roots), then
the design of the Managed Partner Infrastructure plan was such that you can
remove the Legacy Symantec roots, but introduce the Managed Partner
Infrastructure as 'new' roots. For your clients, the path will be seen as
going from Symantec to going to a (shorter) path, but still trusted. Legacy
devices would see the longer path to Legacy Symantec roots, while your
clients would see the shorter path to the Managed Partner Infrastructure.
You would also need to, at a minimum, add the Independently Operated
Sub-CAs as Roots as well, to avoid further disruption to your users.
Unfortunately, on this last point, it does put certain limits on those
Sub-CA operators for transitioning, depending on your client software.
Whitelisting by SPKI is a much better option, but that's dependent upon
your client libraries. This is why it's dangerous irresponsible to ship a
root store that is not bound to a specific set of validation software -
treating validation independently versioned of trust is a recipe for
Assuming your clients cannot whitelist by SPKI, then the other option is to
continue trusting those Legacy Symantec Roots while your customers/clients
use the additional time to migrate from the Managed Partner Infrastructure
onto any other publicly trusted CA, including that of DigiCert's roots
(which have the cross-signs to some of the Legacy Symantec Roots). This
means trusting longer, but reflects that clients other than webservers may
have additional time requirements.
Finally, it's anticipated there will be a third migration, which will be
from the Managed Partner Infrastructure onto DigiCert's roots, at least in
terms of API integration and endpoints. DigiCert would need to share their
timelines for when they see that migration going from the MPI to DC, and
whether there are any other API migrations planned, such as deprecating
some of the legacy APIs (some of which date back to nearly 20 years ago)