> "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.
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.