In 2019, ISRG is going to create a ECDSA root certificate, which is good but ECDSA and P-256 and P-384 curves are not considered very secure by cryptographers. Also P-384 currently is not correctly implemented in OpenSSL (it is extremely slow). I think ISRG should strongly advise CA/B Forum to allow Ed25519 and Ed448 certificates and then focus on quantum computer-resistant signing algorithms.
2 Likes
Hi @anon51109878,
What’s the state of support for these algorithms in browsers and other TLS clients?
Chrome/Chromium already uses Curve25519 as key exchange curve (X25519) in EDHE.
I’m always disappointed when people wait for some other party to implement something. What remains is a chicken and egg dilemma. I already know that even when Chrome/Chromium has some Ed25519 support, it will refuse to implement Ed25519 EdDSA because no CA can issue such certificates.
3 Likes
There was an interesting CA/B Forum thread in December:
https://cabforum.org/pipermail/servercert-wg/2018-December/thread.html#463
5 Likes
Quoting Wayne from that thread:
So, if you are a cryptographer or know one who would like to work on that ticket, thay would be one way to advance the progress of EdDSA in browsers.
4 Likes
What’s the state of support for these algorithms in browsers and other TLS clients?
I just confirmed that curl supports ed25519 as a server certificate type. However, I don't think curl is a member of the CA/B forum 
1 Like
Do you have a source for this claim? As far as I know, CURL uses OpenSSL for it's cryptography and therefore, I recon, would be depending on OpenSSL for Ed25519 support.
It seems that OpenSSL did add some form of support already
including a sample certificate
which my OpenSSL command line can parse with openssl x509.
Great so everything important is done. So please submit a request to the CA/B forum. There is nothing in the way for servers to support Ed25519 and Ed448. So you should get started as soon as possible. Even if they don’t want to support it now. It would be great if you would offer a Ed448 root anyways, so it can be used for m2m communication and because the chicken egg problem is gone, browsers would start supporting it.
On some platforms, anyway.
CentOS/RHEL/Fedora seem to build curl using NSS instead, which hasn't yet implemented EdDSA.
I don't think a single browser of note supports these certificates yet. Not even Chromium, which technically seems to have support in BoringSSL.
I've thrown up a little test server (obviously self-signed) at https://letsdebug.net:25519/ in case anybody wants to test their client support.
2 Likes
Cool, @_az! Could you also make available the public root certificate that you used so that forum readers could see if a few tools are able to verify the chain?
Sure, it’s this RSA 2048 root: https://raw.githubusercontent.com/openssl/openssl/master/test/certs/rootcert.pem
Cool, I got a successful TLS connection with
openssl s_client -CAfile rootcert.pem -build_chain -connect letsdebug.net:25519
and a successful HTTPS connection with
curl --cacert rootcert.pem --connect-to Ed25519:25519:letsdebug.net:25519 https://Ed25519:25519/
Not sure how to make wget happy with the certificate subject unless I add an /etc/hosts entry for ed25519, but
wget --no-check-certificate --ca-certificate=rootcert.pem https://letsdebug.net:25519/
does most likely do some kind of parsing of the certificate in the course of the connection, just without matching its subject name against letsdebug.net.
Anyway, it looks like Ed25519 certificates are a real thing supported by (some) current software!
1 Like
I have claimed that but still there is an internal error with that. Can anyone solve this.