On Sat, Sep 23, 2017 at 6:28 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Fri, Sep 22, 2017 at 1:00 PM, Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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: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 > > > 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.
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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
