CA:MD5and1024

Dates for Phasing out MD5-based signatures and 1024-bit moduli

High Level Summary of Dates:

• December 31, 2010 – All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits. Additionally, CAs with root certificates that have RSA key size smaller than 2048 bits should stop issuing intermediate and end-entity certificates from those roots.
  • DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes: Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010.
    • This means that CAs should only consider issuing a 1024-bit certificate if it is requested and justified by the subscriber for a specific reason, such as interoperability with devices that do not yet support certificates with larger key sizes.
    • The CA must assess the risk involved in issuing such a certificate for legacy use/interoperability, and determine if they are willing to accept the risk, as well as any possible liability. The subject and relying parties also need to determine if they will accept any risks and liabilities.
  • All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013.
    • Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013. This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible.
  • CAs who continue to issue certificates with RSA key size smaller than 2048 bits must use randomness in the serial number or in one of the fields in the DN.

• June 30, 2011 – Mozilla will stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After this date software published by Mozilla will return an error when a certificate with an MD5-based signature is used.
  • bug 650355 - "Stop accepting MD5 as a hash algorithm in signatures (toggle security.enable_md5_signatures to false)" -- Fixed in Mozilla 16 (Firefox 16).
  • bug 590364 - "By default, stop accepting MD5 as a hash algorithm in certificate signatures" - Until this bug is fixed, non-Gecko software that uses NSS will still accept MD5 signatures. (Gecko is the layout engine developed by the Mozilla Project, originally called NGLayout.) -- In NSS 3.14

• December 31, 2013 – Soon after this date, Mozilla will disable the SSL and Code Signing trust bits for root certificates with RSA key sizes smaller than 2048 bits. If those root certificates are no longer needed for S/MIME, then Mozilla will remove them from NSS.
  • TEST: You can test the behavior of changing the root certificate trust bit settings, as described here: https://wiki.mozilla.org/CA:UserCertDB#Changing_Root_Certificate_Trust_Bit_Settings

Note: NSS does not accept MD2 and MD4 as hash algorithms in certificate signatures.

Caveats to proposed dates:

1. Mozilla will take these actions earlier and at its sole discretion if necessary to keep our users safe.
2. CAs may request that their legacy roots be disabled or removed from NSS earlier, according to the Root Change Process
3. There were some long-lived certs that were issued before this policy was put in place; as long as caveat #1 and #2 have not happened and there is no evidence of breaches regarding these certs, these certs may be allowed to expire before the root is removed.
4. Turning off support of < 2048-bit certs is dependent on a code change to build all validation paths. Currently, cross-signing depends on the notAfter/notBefore dates of the certificates in question (which one was issued later). Only one path is built, and if the wrong path is built, the code won't try to build another path. We will need to have the code build all paths, and check another path when the first path fails.

Background

MD5 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for MD5-based signatures. The MD5 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling MD5 will impact intermediate and end entity certificates, where the signatures are validated.

The relevant CAs have confirmed that they stopped issuing MD5 certificates. However, there are still many end entity certificates that would be impacted if support for MD5-based signatures was turned off in 2010. Therefore, we are hoping to give the affected CAs time to react, and are proposing the date of June 30, 2011 for turning off support for MD5-based signatures. The relevant CAs are aware that Mozilla will turn off MD5 support earlier if needed.

The other concern that needs to be addressed is that of RSA1024 being too small a modulus to be robust against faster computers. Unlike a signature algorithm, where only intermediate and end-entity certificates are impacted, fast math means we have to disable or remove all instances of 1024-bit moduli, including the root certificates.

The NIST recommendation is to discontinue 1024-bit RSA certificates by December 31, 2010. Therefore, CAs have been advised that they should not sign any more certificates under their 1024-bit roots by the end of this year.

The date for disabling/removing 1024-bit root certificates will be dependent on the state of the art in public key cryptography, but under no circumstances should any party expect continued support for this modulus size past December 31, 2013. As mentioned above, this date could get moved up substantially if new attacks are discovered. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible.

NIST Recommendations

According to NIST SP 800-57 the recommended algorithms and minimum key sizes are as follows:

• Through 2010 (minimum of 80 bits of strength)
  • FFC (e.g., DSA, D-H) Minimum: L=1024; N=160
  • IFC (e.g., RSA) Minimum: k=1024
  • ECC (e.g. ECDSA) Minimum: f=160
• Through 2030 (minimum of 112 bits of strength)
  • FFC (e.g., DSA, D-H) Minimum: L=2048; N=224
  • IFC (e.g., RSA) Minimum: k=2048
  • ECC (e.g. ECDSA) Minimum: f=224
• Beyond 2030 (minimum of 128 bits of strength)
  • FFC (e.g., DSA, D-H) Minimum: L=3072; N=256
  • IFC (e.g., RSA) Minimum: k=3072
  • ECC (e.g. ECDSA) Minimum: f=256

The NIST document also has this footnote about the SHA-1 Hash Function:

• SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. (SHA-224, SHA-256, SHA-384 and SHA-512)

NIST has provided: DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes. As of September 14, 2010, NIST representatives are addressing the comments and hope to have a final version posted in the next few weeks. The document (dated June 2010) includes the following guidance.

• Digital signature generation:
  • The use of key lengths providing 80 bits of security strength is acceptable for digital signature generation through December 31, 2010.
  • From January 1, 2011 through December 31, 2013, the use of key lengths providing 80 bits of security strength is deprecated. The user must accept risk when using these keys, particularly when approaching the December 31, 2013 upper-limit date. This is especially critical for digital signatures on data whose signature is required to be valid beyond this date. Appendix A.2 provides rationale for this modified guidance. See Section 5.6.2 of [SP 800-57] for further guidance.
  • After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate signatures.
  • Key lengths providing at least 112 bits of security are acceptable.
• Digital signature verification:
  • Key lengths providing 80 bits of security using approved digital signature algorithms are acceptable through 2010.
  • Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010.
  • Key lengths providing at least 112 bits of security using approved digital signature algorithms are acceptable.