On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen <[email protected]> wrote:
> From the perspective of being "clean" from a given NSS version this, > makes sense. However the reality for most situations is there is > demand to support applications and devices with trust stores that have > not been updated for a while. This could be something as similar as > Firefox ESR or it could be a some device with an older trust store. > Assuming there is a need to have the same certificate chain work in > both scenarios, the TLS server may need to send a chain with multiple > root to root cross-certificates. > I'm not sure it's fair to say there needs to be the 'same' certificate chain working in both. The variety of trust stores already shows how that's not necessary today. Merely, one needs to have 'a' certificate chain. Perhaps I've missed a point you weren't stating, but I'm not sure why you would need root-to-root cross-certificates, as this proposal only applies to the roots included in Mozilla's store, and offers a transition path for those roots. > https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just > the roots in each unique disconnected graph. Having the entries there > does not imply that all have cross-signed each other, rather than > there is a path from each pair of roots to a common node. For > example, Root A and Root B might each have a subordinate CA that have > each cross-certified the same, third subordinate. > I'm not sure if you're arguing that this is a desired config, or merely, a config that exists. I certainly would not be willing to suggest CAs have (effectively) managed their cross-certificates well, and it would seem as if some of these paths are reflective of business transitions/deals (and their expirations) rather than intrinsic needs of the Web PKI. As it sounds like you agree that the overall design is both sound and desirable, from a Web PKI perspective, perhaps you could clarify what you believe is a case not supported by this design. This would be useful to understanding what, if any, material consequence there would be of implementing this saner approach to root store management. > Considering we already see paths like: > > OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US => > CN=VeriSign Class 3 Public Primary Certification Authority - G3,OU=(c) > 1999 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust > Network,O=VeriSign\, Inc.,C=US => > 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 => > CN=VeriSign Universal Root Certification Authority,OU=(c) 2008 > VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust > Network,O=VeriSign\, Inc.,C=US => > CN=Symantec Class 3 Extended Validation SHA256 SSL CA,OU=Symantec > Trust Network,O=Symantec Corporation,C=US * => > (End-Entity Certificate) > > I think we need to be careful when considering root rotations. > While a useful real world example, I think the cross-signing activities of several CAs (and one can examine Entrust for a similar issue, or the multiple paths StartCom previously did) are not necessarily designed with either interoperability or consideration of the ecosystem in mind. After all, this is the same set of activities that make it easy for 'forget' disclosure of critical intermediates. Rather, with appropriate advice, one can easily end up with a linear path, where the only 'cost' is paid by legacy systems that don't update, and the servers that need to support such legacy systems. As there is an inherent lifetime for how long something can be 'safely' connected to the Internet, this doesn't seem unreasonable to build upon. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
