Right now all of our root and intermediate keys use RSA. We’re planning to generate ECC keys and make an ECC option available to subscribers in 2016.

Yes, at that moment there wasn’t support in Boulder yet. But now that there is support, one could implement it in the client. And no, why should it be mentioned in the issue? It’s clearly an issue in the letsencrypt / letsencrypt section, not in letsencrypt / boulder or somewhere else :slightly_smiling:

I hope you’ll expand the supported elliptic curves to better ones like Curve25519 when they are finally support in current Browsers, because currently only some curves from the NSA Suite B are supported and they may be a bit flawed. If you follow these links and click a it through you can also find the specific tracking issues about this (at least for Firefox).

From the Let’s Encrypt side of things, they’ll have to wait until the CA/B Forum permits other curves to bring them live. Right now section 6.1.5. of the Baseline Requirements limit all compliant CAs to the NIST curves. This is also reiterated in Let’s Encrypt’s CPS.

Okay. But when the curves are supported in the browser I assume it might not take long until it is also included in the CA/B Baselines.

Baseline_Requirements_V1_3_1.pdf 512.93 KB 6.1.5 Page 29 here are three EC types listed namely P‐256, P‐384 and P‐521 But the P-521 was rejected currently be LE. And from the link (openssl - Which elliptic curve should I use? - Information Security Stack Exchange) you mentioned I'd say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it's also supported in every modern crypto library. So maybe this could be enabled at least ?

secp521r1 is also the only ECC curve which has equal strength to 256 bits AES… As encryption is only as strong as its weakest link, by disabling secp521r1, the use of 256 bits symmetric ciphers isn’t optimal: secp384r1 only provides security equal to a symmetric cipher of 192 bits. In effect, you’re loosing 64 bits of security… Which would be quite regrettable IMHO…

[image] jcjones: It's not supported in Chrome, though. Chrome isn't the only browser out there as far as I've checked. :wink:

[image] jcjones: Speaking of, to quote rlb, "We need a caniuse.com for crypto." The first thing we'd need there would at least be a listing of supported TLS protocol versions. Afterwards we can think about elliptical curves: Add supported elliptical curves (HTTPS/TLS) opened 09:36PM - 20 Jan 16 UTC (UTC) [rugk] rugk Support data suggestion This is related to https://github.com/Fyrd/caniuse/issues/1144, but this issue i…s about the supported elliptical curves in ECDHE connection or ECDSA ciphers. In both cases elliptical curves are used. Here is a current list of supported curves: https://security.stackexchange.com/questions/31772/what-elliptic-curves-are-supported-by-browsers Also discussed on the [Let's Encrypt forum](https://community.letsencrypt.org/t/elliptic-curve-cryptography-ecc-support/34/104?u=rugk).

Currently, the specification for EdDSA certificates (and Curve25519 ECDH for TLS) is under development by the IETF CURDLE WG. It’s going to be a long road until it’s ready for deployment; first the specification needs to get, well, not necessarily done, but stable enough that it can be implemented (consider that the ACME spec isn’t even finalized yet, but we have live implementations). Then you need to add support to probably at least two TLS implementations (OpenSSL is more commonly used on the server side, and NSS more commonly on the client side; if you consider how long it took NSS to support TLS1.2…), and get a resolution in the CA/Browser forum allowing it to be used, and get support into Boulder (which will in turn require support in Go’s crypto libraries and CFSSL – so actually three TLS implementations), and clear whatever other policy hurdles will be in the way. If you want Ed25519 account keys that will also require the Ed25519 for JOSE specification to become reasonably stable and support to be added to the Go implementation of it. If you want Ed25519 intermediates (as opposed to just ECDSA-signed Ed25519 subjects) you’d also need to procure HSMs which support Ed25519 signing, and it’ll probably be a long time before any such HSMs are even available. (Edit: I would also suspect that Let’s Encrypt won’t be able to source Ed25519 cross-signatures from their existing cross-signer, so the most expedient route would be to get an Ed25519 root installed in all root programs, which itself takes time, and that in turn assumes that root programme operators will by then have reached a resolution regarding inclusion of Ed25519 roots.) TLDR: It is going to be a long time before Ed25519 is available, even assuming Let’s Encrypt has the desire to support it.

Elliptic Curve Cryptography (ECC) Support

Feature Requests

jcjones January 20, 2016, 9:24pm 108

It’s not supported in Chrome, though.

Speaking of, to quote rlb, “We need a caniuse.com for crypto.”

Topic		Replies	Views
ECDSA testing on staging Uncategorized	73	28338	July 15, 2016
"EC XXX bits (SHAXXXwithRSA)" versus "EC XXX bits (SHAXXXwithECDSA)"? What's the difference? Does it matter? Issuance Tech	24	6815	August 5, 2022
Should we be defaulting to ECC keys now? Client dev	27	2023	July 22, 2024
Feedback requested: what's standing between you and ECDSA? Site Feedback	22	1024	September 27, 2024
Let's Encrypt new hierarchy plans Issuance Tech	29	10664	August 13, 2020

Elliptic Curve Cryptography (ECC) Support

Related topics