Please support EdDSA certificates

[Darkspirit]

https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/?include_text=1

• go-jose v2 supports Ed25519
• OpenSSL supports Ed25519 & Ed448
• BoringSSL supports Ed25519
• NSS integrates Ed25519

And thank you for Let's Encrypt in general!

[jsha]

Sorry, the doc you linked is still a draft. We won't be issuing EdDSA certificates until they're fully standardized and we do a review of dependencies and the relevant documents that govern issuance.

[Darkspirit]

https://tools.ietf.org/html/rfc8410 🎉
Please reopen ;)

[tdelmas]

@jsha ping?

[jrchamp]

I asked the same question somewhere else and the answer I received back was "CA/B Forum does not allow EdDSA as part of the Baseline Requirements yet". Unfortunately, I don't know where to find updated information on when EdDSA will be in the BR.

[tdelmas]

@jrchamp I found https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868 about it.

[James-E-A]

I found https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868

From that post at the bottom of the thread (authoritative necro by moderator just last Tuesday), we're allegedly just waiting on

• "Browsers need to implement it." (At least Firefox (Nightly) and Google Chrome have since over 2 years ago—so I'm not sure what he meant by this)
• "CA/Browser Forum needs to pass a ballot allowing its use." (I know this isn't LE-specific, it affects all CAs therefore all website owners; but is there anywhere for us webmasters to lurk news on it? My meager google-fu seems to have pretty bleak implications for this topic...)

for LE to be able to sign certs based on the new curve, right?

[tdelmas]

@JamesTheAwesomeDude the last part of the message is a blocking point too:

Note that we won’t be able to generate Ed25519 intermediate certificates until / unless our HSM vendor releases firmware supporting them.

[lilyanatia]

lack of an intermediate doesn't block supporting end entity certificates, as the current status of ECDSA shows.

[jsha]

Please consolidate the conversation over on the forum. Thanks!

[jrchamp]

The forum thread has been locked for over two years and the discussion has been silent for over four. I'm starting to worry that there's a conspiracy to prevent EdDSA from being allowed for public certificates. Instead of "here's what Let's Encrypt is doing to make this happen", it's been "here's why we can't make it happen, so it's time to close or lock the thread". I don't want to believe that the EFF is being silenced by the federal government, but the completely stalled progress and silence on the matter is suspicious.

[Darkspirit]

I wouldn't file this feature request again today, it's okay that it has been closed. Personally I try to avoid Ed25519, P-256, RSA below 4096 bits and think we should focus on using P-384 certificates for S/MIME and TLS (and maybe Ed448 if browser engine and mail app developers have found reasons to think that the effort could be worth it, so no need to hurry).

[lilyanatia]

Personally I try to avoid Ed25519, P-256, RSA below 4096 bits and think we should focus on using P-384 certificates for S/MIME and TLS (and maybe Ed448 if browser engine and mail app developers have found reasons to think that the effort could be worth it, so no need to hurry).

why? the only reason to avoid Ed25519 or P-256 is if you're worried about quantum computers, and that affects ECDSA, EdDSA, and RSA at any key size. there's just enough suspicion around the NIST curves to prefer Ed25519 and Ed448 over P-256 and P-384 whenever possible. RSA at any acceptable key size is just way too slow to be practical.

also, P-384 is abysmally slow in OpenSSL, even slower than 2048-bit RSA:

	sign/s
P-256	16159.3
Ed25519	10395.9
Ed448	1687.4
RSA 2048	613.0
P-384	508.2
RSA 3072	202.9
RSA 4096	104.3

[lmamane]

there's just enough suspicion around the NIST curves to prefer Ed25519 and Ed448 over P-256 and P-384 whenever possible.

Exactly. That.