On Thu, Feb 15, 2018 at 9:37 AM, Kai Engert via dev-security-policy < [email protected]> wrote: > > 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 Infrastructure. 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 certificates. 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, bar-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 long-term disaster. 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) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
