On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Sometimes, CAs apply for inclusion with new, clean roots. Other times, >> CAs apply to include roots which already have a history of issuance. The >> previous certs issued by that CA aren't always all BR-compliant. Which >> is in one sense understandable, because up to this point the CA has not >> been bound by the BRs. Heck, the CA may never even have heard of the BRs >> until they come to apply - although this seems less likely than it would >> once have been. >> >> What should our policy be regarding BR compliance for certificates >> issued by a root requesting inclusion, which were issued before the date >> of their request? Do we: >> >> A) Require all certs be BR-compliant going forward, but grandfather in >> the old ones; or >> B) Require that any non-BR-compliant old certs be revoked; or >> C) Require that any seriously (TBD) non-BR-compliant old certs be >> revoked; or >> D) something else? >> > > D) Require that the CA create a new root certificate to be included within > Mozilla products, and which all future BR-compliant certificates will be > issued from this new root. In the event this CA has an existing root > included within one or more software products, this CA may cross-certify > their new root with their old root, thus ensuring their newly-issued > certificates (which are BR compliant) work with such legacy software. > > This ensures that all included CAs operate from a 'clean slate' with no > baggage or risk. It also ensures that the slate always starts from "BR > compliant" and continues forward. > > However, some (new) CAs may rightfully point out that existing, 'legacy' > CAs have not had this standard applied to them, and have operated in a > manner that is not BR compliant in the past. > > To reduce and/or eliminate the risk from existing CAs, particularly those > with long and storied histories of misissuance, which similar present > unknowns to the community (roots that may have been included for >5 years, > thus prior to the BR effective date), require the same of existing roots > who cannot demonstrate that they have had BR audits from the moment of > their inclusion. That is, require 'legacy' CAs to create and stand up new > roots, which will be certified by their existing roots, and transition all > new certificate issuance to these new 'roots' (which will appear to be > cross-signed/intermediates, at first). Within 39 months, Mozilla will be > able to remove all 'legacy' roots for purposes of website authentication, > adding these 'clean' roots in their stead, without any disruption to the > community. Note that this is separable from D, and represents an effort to > holistically clean up and reduce risk. > > The transition period at present cannot be less than 39 months (the maximum > validity of a newly issued certificate), plus whatever time is afforded to > CAs to transition (presumably, on the order of 6 months should be > sufficient). In the future, it would also be worth considering reducing the > maximum validity of certificates, such that such rollovers can be completed > in a more timely fashion, thus keeping the ecosystem in a constant 'clean' > state.
>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. To get a feel for how long a not looping path might be, I recently pulled trust stores for dozens of versions of Windows, Netscape, Mozilla, and Java. I then used unexpired cross-certificates from CT to group these trust anchors into unique clusters or disconnected graphs. The results are available as gists. 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. https://gist.github.com/pzb/ffab25cbe7d32c616792a5dec3711315 is the same data with all the unexpired subordinate cross-certificates included. Note that the clustering does not take into account anything besides expiration; for example it is possible that two paths to a common node have conflicting constraints. 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. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
