# Ed25519 ACME account support **URL:** \ **Category:** Feature Requests\ **Created:** [May 13, 2019, 12:35pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459 "2019-05-13T12:35:20Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![ndilieto](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ndilieto/32/31359_2.png) [@ndilieto](https://community.letsencrypt.org/u/ndilieto)\ **Post date:** [May 13, 2019, 12:35pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/1 "2019-05-13T12:35:20Z")
From Section 6.2 of RFC8555, [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555#section-6.2) > 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? ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [May 13, 2019, 1:26pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/2 "2019-05-13T13:26:01Z")
Hi @ndilieto > [@ndilieto](#): > > Ed25519 is arguably one of the most secure and efficient cryptographic algorithms. please read > [@Support Ed25519 and Ed448](https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868): > > I… 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. ---
**Author:** ![ndilieto](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ndilieto/32/31359_2.png) [@ndilieto](https://community.letsencrypt.org/u/ndilieto)\ **Post date:** [May 13, 2019, 1:49pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/3 "2019-05-13T13:49:14Z")
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. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [May 13, 2019, 10:32pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/4 "2019-05-13T22:32:17Z")
Support for EdDSA in JOSE was standardized in [https://tools.ietf.org/html/rfc8037](https://tools.ietf.org/html/rfc8037) , and the JOSE library used by Boulder already supports it. So it can probably be done. ---
**Author:** ![ndilieto](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ndilieto/32/31359_2.png) [@ndilieto](https://community.letsencrypt.org/u/ndilieto)\ **Post date:** [May 14, 2019, 5:59am UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/5 "2019-05-14T05:59:39Z")
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](https://github.com/letsencrypt/boulder/blob/master/wfe2/verify.go) It can’t be that simple, can it? ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [May 14, 2019, 1:08pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/6 "2019-05-14T13:08:04Z")
Thanks for opening a thread about this @ndilieto 👍 > [@\_az](#): > > Support for EdDSA in JOSE was standardized in [RFC 8037 - CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)](https://tools.ietf.org/html/rfc8037) , and the JOSE library used by Boulder already supports it. Though having spotted [this fix upstream](https://github.com/square/go-jose/commit/86617ab13c8de6712933702a25a3c287054e5e2b) 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. > [@ndilieto](#): > > 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](https://github.com/letsencrypt/boulder/blob/master/wfe2/verify.go) > > It can’t be that simple, can it? 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](https://github.com/letsencrypt/boulder/blob/master/wfe2/verify.go#L619-L623). The RA also vets all new v1 registration keys and v2 account keys [the same way](https://github.com/letsencrypt/boulder/blob/6e06f36309e9defd6fcd5aae7958b4122a99581e/ra/ra.go#L297-L299). The relevant code for that is mostly in `goodkey/good_key.go`. Like with `sigAlgorithmForKey` in the WFE2 the [Goodkey](https://github.com/letsencrypt/boulder/blob/master/goodkey/good_key.go#L70) 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](https://github.com/letsencrypt/boulder/blob/6e06f36309e9defd6fcd5aae7958b4122a99581e/ra/ra.go#L966-L968)). It's unlikely we will be able to support EdDSA in subscriber certificates ([see the other thread](https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868)) 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? ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [May 14, 2019, 1:23pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/7 "2019-05-14T13:23:11Z")
> [@cpu](#): > > A well-written PR on Boulder with good test coverage would be harder to say no to I transferred some of my message above into a Boulder issue for the feature request: [Support EdDSA account keys · Issue #4213 · letsencrypt/boulder · GitHub](https://github.com/letsencrypt/boulder/issues/4213) ---
**Author:** ![ndilieto](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ndilieto/32/31359_2.png) [@ndilieto](https://community.letsencrypt.org/u/ndilieto)\ **Post date:** [May 14, 2019, 2:12pm UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/8 "2019-05-14T14:12:39Z")
> [@cpu](#): > > 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. I totally agree with you. Cryptographic software is 1% coding and 99% review. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [May 16, 2019, 12:55am UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/9 "2019-05-16T00:55:21Z")
That’s a great summary @cpu, thank you! ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [June 15, 2019, 1:05am UTC](https://community.letsencrypt.org/t/ed25519-acme-account-support/93459/10 "2019-06-15T01:05:22Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.