This request should have been made to CAB Forum, but I could not find a feedback channel from CAB Forum to the public.
And since ISRG is a member of the CAB Forum and Let's Encrypt is one of the major certificate brands on the Internet, I am posting my request here.
According to the information provided by SafeCurves, Curve25519 is safe, while Cloudflare considers the Curve25519 variants X25519Kyber512Draft00 and X25519Kyber768Draft00 to be post-quantum.
So why don't we use Ed25519 and Ed448 etc. for server certificates?
The absence of EdDSA in TLS Ciphersuite surprised me, why exactly is all this?
I don't know much about cryptography and I hope someone can help me.
6.1.5 Key sizes
For RSA key pairs the CA SHALL:
• Ensure that the modulus size, when encoded, is at least 2048 bits, and;
• Ensure that the modulus size, in bits, is evenly divisible by 8.
For ECDSA key pairs, the CA SHALL:
• Ensure that the key represents a valid point on the NIST P‐256, NIST P‐384 or NIST
P‐521 elliptic curve. No other algorithms or key sizes are permitted.
7.1.3.1.2 ECDSA
The CA SHALL indicate an ECDSA key using the id‐ecPublicKey (OID: 1.2.840.10045.2.1)
algorithm identifier. The parameters MUST use the namedCurve encoding.
• For P‐256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
• For P‐384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).
• For P‐521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).
When encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte‐for‐byte
identical with the following hex‐encoded bytes:
• For P‐256 keys, 301306072a8648ce3d020106082a8648ce3d030107.
• For P‐384 keys, 301006072a8648ce3d020106052b81040022.
• For P‐521 keys, 301006072a8648ce3d020106052b81040023.
There's not a huge advantage of the Ed25519/Ed448 over the supported NIST curves, so there's not a lot of push. In contrast, P256 certs are a lot smaller than RSA2048 so there is some motivation to upgrade there.
Well, depending on just how much one distrusts NIST and/or the NSA regarding the process they used to make P-256, one might think that there could be vulnerabilities (or at least suboptimal choices) in it which would mean that the EdDSA curves have enough of a "huge advantage" to be worth pushing. (And then one might be suspicious of why EdDSA curves have gained a lot of traction in other applications like SSH, PGP, and the DH key exchange of newer TLS, but not in TLS server authentication.) Certainly the authors of that "Safecurves" site think that there are downsides to the NIST curves, though I myself similarly don't have enough cryptography knowledge to understand just how bad the problems with it might be.
Still, I do agree with @wordlesswind's request: I also would like to see support for EdDSA. The ED curves are much better than NIST's in many aspects.
Sadly, the current state is that most implementations don't support EdDSA certificates: I run a test site myself (ed25519-test.germancoding.com) where you can check whether your TLS client accepts these certificates. If you see an error message similar to "NO_CYPHER_OVERLAP" or "CIPHER_MISMATCH" it means that your client does not support EdDSA*, while a standard certificate verification error (untrusted root) probably means that it is supported. If you want to confirm, temporarily trust the root certificate from here (due to BR requirements it's impossible to get a public cert right now).
Once browsers have implemented EdDSA it makes sense to push for allowance in the BRs. But right now the initiative appears to be a bit slow. Still, hopefully requests like this keep the goal alive!
The post-quantum aspect isn't really relevant though: The Cloudflare article you linked talks about Kyber, a post-quantum key encapsulation method (or a hybrid form of it). AFAIK, you can't do post-quantum safe cryptography with neither ECDSA nor EdDSA. In any case, this is talk about key exchange/key agreement, while certificates (where EdDSA comes into play) are all around signatures & authentication - two different animals. If you are worried about quantum algorithms, you will likely want to aim for an entirely different class of algorithms. The current state of the art crypto is often unsuitable for PQ.
*(Modern) OpenSSL does support EdDSA, and probably a bunch of other non-browser implementations. Within the browser world it gets really sparse.
You can officially participate in CA/B Forum without being a browser or CA by becoming an Interested Party, as an individual or organization. You can't vote or propose ballots, but you can participate in the discussions. I did this as part of my old job in order to participate in the discussion about certificates for onion sites.
CA/B Forum would definitely prefer if people who go through this process can contribute to the discussion in a substantive way, but I think the minimum requirement is just to be respectful of the other members and their time.
Also, anyone can subscribe to (most) CA/B Forum mailing lists, such as servercert-wg, where (most) discussions happen. You don't need to be a Member or Interested Party to do this. However, only Members or Interested Parties are allowed to post to the lists.