Add policy about old root certificates

[WilsonKathleen]

We should add policy about old root certificates, e.g.:

1. Not accepting inclusion requests for root certificates created before a certain date.
2. CAs that currently have root certificates in our program that were created before a certain date should be migrated to newer root certificates.
   The policy should give the overall guidance, and link to a wiki page with details.

Ben started discussion about this here:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TII3OVNINEM/m/ysMqglFqFAAJ

[BenWilson-Mozilla]

Additional factors to creation date could be: expiry date, key size, trust bits, subCA quantity and characteristics (including number of CAs externally operated by third parties), key protection, audit history, and whether organization name in certificate matches current owner/operator.

[BenWilson-Mozilla]

According to NIST Special Publication 800-57, Part 1, Rev. 5, a 2048-bit RSA key can only provide up to 112 bits of security strength when using conventional computing. NIST SP 800-57 says that this is too weak to provide sufficient assurance past 2030. Furthermore, we need to address the threat presented by quantum computers and start encouraging the move to post-quantum crypto algorithms (Dilithium and Falcon) as soon as these are standardized.

[BenWilson-Mozilla]

See post here: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/PuI1ZILqZ7o/m/E-cKaw_jBAAJ

[BenWilson-Mozilla]

According to https://www.chromium.org/Home/chromium-security/root-ca-policy/, Chrome will have a future policy that may limit the root CA certificate use to 7 years, "measured from the initial date of certificate inclusion. ... CA operators would be encouraged to apply with a replacement CA certificate after 5 years of inclusion,...." (Chrome also has a policy that key material must be generated within 5 years of application.) Maybe Mozilla could adopt similar wording that limits the usability of root CAs for TLS to something like 12 years (and, e.g., 20 years for S/MIME-enabled roots). The cadences for CA operators to file inclusion requests for replacement root certificates will likely be different among root store operators, as there are differences with root store processing times today. One of the underlying policy concerns is future-proofing CAs to account for increased computing capability, so there will need to be some type of "freshness" metric as well. These two ideas could be combined into one requirement that limits the use of roots for TLS to 15 years, as measured from the creation of key material. Or maybe it is better just to keep separate the currently-used metrics for various CA lifetime factors (e.g. key generation date, root submission date, CA certificate lifetime/expiration date, etc.)?

[BenWilson-Mozilla]

As mentioned here, https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/-qSvEhaHs1c/m/VUjfxK00AQAJ,
the current thinking is that the policy should be revised to state as follows:

Section 7.4 “Root CA Life Cycles” 

Root CA certificates included in the Mozilla root store will be distrusted when their CA key material is over 15 years old. The date of CA key material generation SHALL be determined by reference to the auditor’s key generation ceremony report. For key material generated before July 1, 2012, Mozilla will assume that the key material was generated on the “Valid From” date in the root CA certificate. For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the following schedule:  

Key Material Created	Distrust Date
Before January 1, 2006	April 15, 2025
2006-2007	April 15, 2026
2008-2009	April 15, 2027
2010-2011	April 15, 2028
2012- April 14, 2014	April 15, 2029
April 15, 2014 - present	15 years from creation

This schedule is subject to change if the underlying algorithms become more susceptible to cryptanalytic attack.

CA operators MUST apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the Distrust Date above.

[BenWilson-Mozilla]

Change the second-to-last sentence to read, "This schedule is subject to change if underlying algorithms become more susceptible to cryptanalytic attack or if other circumstances arise that make this schedule obsolete."

[BenWilson-Mozilla]

I've removed this from the branch for 2.8.1 - BenWilson-Mozilla@5cb82e4