Update algorithms and key sizes list

[gerv]

After discussion in m.d.s.policy, the following changed was proposed by Kathleen and received a reasonable amount of support with no dissent. It is to change section 8 of the Maintenance section of the policy to, instead of explicitly listing all the algorithms, read as follows:

8. We consider the algorithms and key sizes specified in section 6.1.5 of version 1.3 or later of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates to be acceptable and supported in Mozilla products; with the following exceptions.

• Mozilla does not and will not support DSA keys
• Mozilla does not currently support ECC curve P-521

Note that this might have an effect on the scope of any SHA-1 ban, because Mozilla's policy is scoped differently to the BRs.

[briansmith]

This originated out of my proposal to rationalize the algorithms. Part of my proposal was to match the ECC curve with the corresponding SHA-2 digest algorithm: P-256 with SHA-256, P-384 with SHA-384.

Back when this was being discussed on the mailing list, there wasn't consensus to become that strict. However, subsequently David Benjamin from Google reported "I'd also found no ECDSA/SHA-1 or ECDSA/SHA-512 certificates in CT logs," in https://groups.google.com/a/chromium.org/d/msg/security-dev/SlfABuvvQas/HXaWVhZkBQAJ, which is good evidence that the stricter matching won't be harmful.

Further, the IETF TLS working group did accept my suggestion for specifying curves and digest algorithms in pairs. See https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.2.3 and note that for ECDSA TLS 1.3 can only express these pairings:

      ecdsa_secp256r1_sha256 (0x0403),
      ecdsa_secp384r1_sha384 (0x0503),
      ecdsa_secp521r1_sha512 (0x0603),

That suggestion was informed by our work in the webpki and ring projects, where we have been able to simpler and less-error-prone APIs by pairing things in such ways.

Further, fixing the hash algorithm per curve is consistent with Ed25519, where only one digest algorithm (SHA-512) is allowed. It is time to add Ed25519 as an allowed algorithm as well.

Considering all this new information, the proposed change should be reconsidered.

[gerv]

Considering all this new information, the proposed change should be reconsidered.

@briansmith: Can you propose alternative text?

[briansmith]

@briansmith: Can you propose alternative text?

Please see #37 and #38. If people agree with all of these then it would make sense to have the Mozilla policy specify the exact AlgorithmIdentifiers that are allowed, instead of deferring to the baseline requirements, unless/until the baseline requirements can be fixed. If people agree with this then I'll be happy to write it up, but first it would be good to get people to agree.

[gerv]

@briansmith: I am unable to evaluate the wisdom of your proposals; I think you'd need to seek agreement in mozilla.dev.tech.crypto. If our NSS hackers are fine with these restrictions, and we think that policy rather than code is the right place to put them (is it because the requirements are broken now, and we need to enforce a fix in policy before we can make one in code?) then I'm happy with it.

[briansmith]

(is it because the requirements are broken now, and we need to enforce a fix in policy before we can make one in code?

The goal is exactly to make it easier for Mozilla and others to build simpler, safe, tested, and interoperable implementations of these things.

In particular, as we've seen in the past, some CAs haven't been encoding certificates according to the specifications, so most of these proposals are to emphasize the specific points of non-interoperability that CAs should pay special attention to.

In some cases, such as the more specific ECDSA and PSS parameter suggestions, these have already been accepted by various IETF working groups recently, but there's no one specification general specification to point at. See for example, https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-10, in particular:

The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.

Notice that my recommendations are almost exactly the TLS 1.3 recommendation above, which was written by EKR and which I believe is already supported various Mozillians have been working on TLS 1.3. Of course, it isn't absolutely required that we make the same choices in the Web PKI as we make in TLS, but it is a good idea, IMO.

[gerv]

Final agreed text from discussion:

We consider the following algorithms and key sizes to be acceptable in
root certificates in our root program, and in any certificate which
chains up to them:

• RSA keys whose modulus size in bits is divisible by 8, and is at
  least 2048.
• Digest algorithms: SHA-256, SHA-384, or SHA-512.
• ECDSA keys using one of the following curve-hash pairs:
  • P‐256 with SHA-256
  • P‐384 with SHA-384

[briansmith]

RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.

Aren't there a lot of 2047-bit keys in widespread use? If you multiply two small 1024-bit (private) primes, the result is a 2047-bit public modulus, not a 2048-bit public modulus.

[gerv]

While you are technically correct, which is normally the best kind of correct :-), in practice NSS's implementation treats such keys as 2048-bit with a leading 0, which makes them both divisible by 8 and also inside the policy as worded. Given that Mozilla has no plans to censure CAs using such moduli, I think the intent is clear and the implementation is clear, so we can leave the wording in its current simple form.