On Fri, Sep 22, 2017 at 1:00 PM, Peter Bowen via dev-security-policy < [email protected]> wrote: > > 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:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f3 > 5ec6,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:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384d > f058, > 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:25b41b506e4930952823a6eb9f1d31 > def645ea38a5c6c6a96d71957e384df058, > 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:25b41b506e4930952823a6eb9f1d31def645ea38a5c6c6a96d71957e384d > f058, > 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
Peter, Thanks a ton for sharing the challenges some customers face. It’s unclear, however, why it’s necessary to re-use the existing key, particularly in browser-based applications, so hopefully that can be expanded upon. If we take the existing path: 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 Then the proposal I was suggesting was to instead consider the following: 1) End-entity info 2z) spkisha256:<TBD>,KeyID:<TBD>, DN:CN=New Server Issuing CA, O=DigiCert, C=US, 3z) spkisha256:<TBD>,KeyID:<TBD>, DN:CN=Managed CA, O=DigiCert, 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 Where both 2z and 3z are operated by the Managed CA, wholly on the Managed CA’s infrastructure. Based on the public discussions to date, the actual implementation of the transition begins to look like: Any certificate that chains to 3 with a notBefore > 2017/12/01 is not trusted, unless it transits 3z. This is landed in code around 2017/12/01. Any certificate that chains to 3 with a notBefore < 2016/06/01 is not trusted, beginning sometime early in 2018 (e.g. Chrome 66) 3 is removed from the root store, while 3z is added, sometime in late 2018 (e.g. Chrome 70) This provides a transition path for those implementing something similar to what Google Chrome and Mozilla Firefox have announced. Other vendors that have not commented to date on their plans could implement something similar, or they could adopt a plan of: At some point in the future, 3 is removed from the root store, while 3z is added. Finally, for devices and applications that do not update their limited trust stores, 3 remains present in the chain to support them, thus supporting both modern and legacy clients equally effectively. For browsers, this allows sites until late 2018 to fully complete a migration of any HPKP-pinned websites, representing a substantially long transition window. For operating systems and platforms, they can evaluate both the compatibility risks to their overall platforms and applications, as well as look at similar or alternative mitigations. The important difference in this plan between your proposed 3b and my suggested 3z is that 3z has greater assurances with respect to the protection and generation of the key material, which addresses some of the concerns raised with the existing infrastructure. Adding 3b to the root stores still leaves the risk of trusting the legacy infrastructure, while 3z would be starting from a known-good point and continuing to work forward. I don’t think there’s an intent of a ‘relatively soon’ replacement of the root - as outlined, that’s proposed for 2018 with the full distrust. Programmatic enforcement, for those that wish to mitigate the risk during the transition period, can be done soon, while the replacement of the root - which represents distrusting all existing certificates - is deferred until 2018. Do you think that addresses your concerns? As I tried to highlight, the one notable downside to this is that applications or sites that exclusively pinned to 2 (spkisha256:f67d22cd39d2445f96e16e094eae756af49791685007c76e4b66f154b7f35ec6) will be affected, but so far, there hasn’t been a solution identified that could allow that key to still be used without still trusting the legacy infrastructure, which doesn’t work. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
