On Thu, Sep 21, 2017 at 7:17 PM, Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > I think we can divide the discussion into two parts, similar to the > previous mail: How to effectively transition Symantec customers with > minimum disruption, whether acting as the Managed CA or as the future > operator of Symantec’s PKI, and how to effectively transition DigiCert’s > infrastructure. This is a slightly different order than your e-mail > message, but given the time sensitivity of the Symantec transition, it > seems more effective to discuss that first. > > I think there may have been some confusion on the Managed CA side. It’s > excellent that DigiCert plans to transition Symantec customers to DigiCert > roots, as that helps with an expedient reduction in risk, but the plan > outlined may create some of the compatibility risks that I was trying to > highlight. In the discussions of the proposed remediations, one of the big > concerns we heard raised by both Symantec and site operators was related to > pinning - both in the Web and in mobile applications. We also heard about > embedded or legacy devices, and their needs for particular chains. > > It sounds like this plan may have been based on a concern that I’d tried to > address in the previous message. That is, the removal of the existing > Symantec roots defines a policy goal - the elimination in trust in these > legacy roots, due to the unknown scope of issues. However, that goal could > be achieved by a number of technical means - for example, ‘whitelisting’ a > set of Managed CAs (as proposed by Chrome), or replacing the existing > Symantec roots with these new Managed CA roots in a 1:1 swap. Both of these > approaches achieve the same policy objective, while reducing the > compatibility risk.
Ryan, As an existing Symantec customer, I'm not clear that this really addresses the challenges we face. So far we have found several different failure modes. We hope that any solution deployed will assure that these don't trigger. First, we found that some clients have a limited set of roots in their trust store. The "VeriSign Class 3 Public Primary Certification Authority - G5" root with SPKI SHA-256 hash of 25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058 is the only root trusted by some clients. They do, somewhat unfortunately, check the certificate issuer, issuer key id, and signature, so they changing any will break things. However they don't update their trust store. So the (DN, key id, public key) tuple needs to be in the chain for years to come. Second, we have found that some applications use the system trust store but implement additional checks on the built and validated chain. The most common case is checking that at least one public key in the chain matches a list of keys the application has internally. As there is an assumption that the current root (DN, public key) tuples will be replaced relatively soon by some trust store maintainers, there needs to be a way that that both of these cases can work. The only way I can see this working long term on both devices with updated trust stores as well as devices that have not updated the trust store is to do a little bit of hackery and create new (DN, public key) tuples with the existing public key. This way apps with pinning will work on systems with old trust stores and one systems with updated trust stores. As a specific example, again using the Class 3 G5 root, today a chain looks like: 1) End-entity info 2) spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6,KeyID:5F:60:CF:61:90:55:DF:84:43:14:8A:60:2A:B2:F5:7A:F4:43:18:EF, DN:CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust Network, O=Symantec Corporation, C=US, 3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058, KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33, DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc., C=US If there is a desire to (a) remove the Class 3 G5 root and (b) keep the pin to its key working, the only solution I can see is to create a new root that uses the same key. This would result in a chain that looks something like: 1) End-entity info 2b) spkisha256:<tbd>,KeyID:<tbd>, DN:CN=New Server Issuing CA, O=DigiCert, C=US, 3b) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058, KeyID:6c:e5:3f:7b:45:1f:66:b4:e6:7c:70:05:86:19:79:4f:a6, DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU=DigiCert Compatibility Root, OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc., C=US 3) spkisha256:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384df058, KeyID:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33, DN:CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU=(c) 2006 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network, O=VeriSign\, Inc., C=US Note that 3b and 3 have the same public key and intersecting sets of attributes in the DN, but have different key IDs and different DNs. In order for this to work, 3b would have to be included in new trust stores. This likely implies that 3b is created under new controls (e.g. by DigiCert), but presumably this cannot happen until the deal closes. If this doesn't happen prior to December 1, then there will likely need to be an interim phase where a different issuing CA is created by DigiCert that is signed by #3 -- something like "CN=Symantec Class 3 Secure Server CA - GD1, OU=Symantec Trust Network, O=Symantec Corporation, C=US". This would be the "Managed CA". I realize this is somewhat more complex than what you, Ryan, or Jeremy proposed, but it the only way I see root pins working across both "old" and "new" trust stores. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
