From Section 6.2 of RFC8555, RFC 8555 - Automatic Certificate Management Environment (ACME)
An ACME server MUST implement the "ES256" signature algorithm [RFC7518] and SHOULD implement the "EdDSA" signature algorithm using the "Ed25519" variant (indicated by "crv") [RFC8037].
Ed25519 is arguably one of the most secure and efficient cryptographic algorithms. Would it be possible to add support for it in Let's Encrypt?
Hi @ndilieto
please read
With an answer from @jsha
Chrome is supportive of these algorithms and would like to include them in Chrome, but has nothing concrete to share at this time.
I am aware of that thread but I was just referring to Ed25519 in the context of the ACME protocol. In other words, what I asked for is support of Ed25519 account keys, not Ed25519 certificates.
Just as it is possible to request RSA certificates using a P-256 account key, I think RFC8555 6.2 just says it SHOULD be possible to do the same using an Ed25519 account key.
Support for EdDSA in JOSE was standardized in https://tools.ietf.org/html/rfc8037 , and the JOSE library used by Boulder already supports it.
So it can probably be done.
If that is the case, I wonder if it’s just a matter of adding EdDSA to the sigAlgorithmForKey function on line 46 of https://github.com/letsencrypt/boulder/blob/master/wfe2/verify.go
It can’t be that simple, can it?
Thanks for opening a thread about this @ndilieto 
Though having spotted this fix upstream I'm somewhat glad we hadn't adopted it immediately. 
For me this kind of issue is a great reminder that adding support for new cryptographic algorithms carries fairly significant risk and requires careful review above and beyond piping together the right libraries and code.
It will be a little bit more involved than that. The validSelfAuthenticatedJWS function in wfe2/verify.go that will be used when evaluating JWS with embedded JWK (like for newAccount) also calls out to a key policy object and its GoodKey function. The RA also vets all new v1 registration keys and v2 account keys the same way.
The relevant code for that is mostly in goodkey/good_key.go. Like with sigAlgorithmForKey in the WFE2 the Goodkey function outwards would need to support EdDSA, with a particular eye towards anywhere we might need to verify the public key's parameters above and beyond what may be done by go-jose.
Updating goodkey is complicated by the fact that the same package/functions are used by the RA and the CA to verify CSR public keys (e.g. the RA verifying a CSR during order finalization). It's unlikely we will be able to support EdDSA in subscriber certificates (see the other thread) anytime soon so the goodkey package would need to be modified to know whether it was verifying an account key or a CSR key. (Again this is a change that makes my spider sense tingle: we would be adding a joint where there wasn't one before and if it bends the wrong way in production because of a bug we could disastrously allow a Ed25519 public key in a subscriber certificate. This would be a misissuance and have to be reported in that year's audit and to the root programs).
I'm not sure if there is any specific reason we haven't evaluated Ed25519 account keys before now. I agree it seems possible, I disagree that it's necessarily simple. Like most things I think it's primarily a question of prioritization. My personal opinion is that I think this falls more into the nice-to-have category. A well-written PR on Boulder with good test coverage would be harder to say no to 
@jsha Do you have any other thoughts?
I transferred some of my message above into a Boulder issue for the feature request: Support EdDSA account keys · Issue #4213 · letsencrypt/boulder · GitHub
I totally agree with you. Cryptographic software is 1% coding and 99% review.
That’s a great summary @cpu, thank you!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.