"Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]"
I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448.
> Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves.
Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.
> "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]"
This is oversold, if not simply factually incorrect.
RFC 8446 says
> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519
x448 is not mandatory. x25519 is not mandatory, it's only a SHOULD. In addition, key exchange is for diffie-hellman ephemeral keys; that's separate from the keys used in the certificate. I don't think there's widespread support for X25519 (or X448) in X.509 certificates.
There’s a small point of terminology that’s important for getting a clear idea of the state of support for curve25519 in IETF protocols.
X25519 is the name used for key exchange (Diffie-Hellman) which has been widely supported for some years now since it was added to TLS.
Ed25519 is the name used for digital signatures (Ed is short for Edwards) which is what you need for certificates. It was a few years later to arrive in OpenSSL because TLS didn’t need it.
Note that this document is (of course) not an implementation, or even an explanation of how to implement support for this, but only a description of how to spell X25519 in ASN.1 in order to write it into a PKIX X.509 certificate.
So this document is a precursor to widespread support for X25519 in certificates only in the same way that coming up with a name for your kid is a precursor to giving birth. It's not strictly necessary, and it's certainly not the most important thing you needed to do, but I guess it can be part of the process.
> A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
TLS 1.3 is - in browser-centric scenarios - about 50% of clients today. Put another way: at least half of the internet does not support TLS 1.3, and that is larger still if you are in the embedded, large enterprise or similar spaces.
It will take a while to close out that last 50%, and I do not blame Let’s Encrypt for taking the clearly practical approach here (by far).
Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate.
They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys.
Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa).
Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature.
The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use.
If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key.
They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.
Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
I'm not so sure about that.
https://en.wikipedia.org/wiki/Curve25519#History
"Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]"
I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448.
> Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves.
Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG
Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.