On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < [email protected]> 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
