If you would like your account to be allow-listed for ECDSA issuance in Production, please fill out this form: https://forms.gle/ftKeqkj6AJgXUDPJ8
We'll be processing allow-list requests in batches, most of which will go out Thursday with our normal Production updates.
Will you be sending a message to the contact address of accounts that are added to the production update list or should we expect the change will happen at some point without notification?
We are sending out confirmation notifications after the list is updated to the address provided in the form. There are a few wrinkles in the process that we're working to smooth out so this week's update is a little behind. We'll be improving it over the next week so there is less guessing involved.
I laso didnt get any confirmation email yet, however since it was said allow list gets updated after maintenance i just tried to issue new cert from E1 on thursday, couple of hours after maintenance and it was already working.
I also got upgraded to ECDSA chain without receiving any e-mail confirmation.
Anyway, my question is: would it be possible to provide alternate chain that would extend the current chain with the ISRG Root X1 certificate cross-signed by DST Root CA X3? This would help in minor cases where ISRG Root X1 is still not in trust chain. So the chain would be on par with current default RSA chain.
I feel like this is a very valid concern. While ECDSA certificates are respectively new, I don't think it's reasonable to assume that the set of devices that support ECDSA certificates is a subset of the set of devices that trust ISRG Root X1.
This is possible, but not currently planned. ECDSA offers many benefits including fewer bytes per transaction so we're only offering the shortest, compatible chain for now.
I think that it's pretty close to being true though, in that I know somewhere somebody said that there were some old Android versions that couldn't handle the P-384 signatures that the Let's Encrypt ECDSA chain uses. For the most part, if you need compatibility with older systems then you should still use RSA certificates. And if you don't, then your systems are probably new enough to have the ISRG Root cert. And even if they aren't, having the chain all the way up to the DST Root may be long enough that you're not getting much of an advantage by switching to ECDSA anyway.
But regardless of the chains returned through the ACME endpoint, if one really want to go that route one could configure one's servers to send the really long leaf ← E1 ← ISRG Root X2 ← ISRG Root X1 ← DST Root CA X3 chain. You'd want to take care with your automation to handle well the case when the intermediate changes, but as long as you have your script or whatever just look for the chain ending in ISRG-Root-X2-signed-by-Root-X1 and append the Root-X1-signed-by-DST cert after it, I'd think it would be fairly resilient. Just using RSA certificates with the default ACME chain is probably a lot easier than setting all that up, though.
I agree, @petercooperjr. Aside from sending less bytes and any savings in processing, from a functional standpoint EC seems to me to be mostly about preference unless RSA were to be compromised or EC were to be proven strictly superior from a security standpoint. Barring the latter scenarios, there wouldn't really be a "need" to maximize support for EC.
I'd like to thank everyone for their patience while we work to update the ECDSA allow-list and send notifications on a timely schedule. We held back the last two boulder release tags because of errors found during our tests of those builds. As a result, our planned Thursday updates of the ECDSA allow-list got a little delayed. The allow-list is now up-to-date for all entries submitted through end-of-day on May 19th. If you don't recall when you submitted, e-mails will be sent soon and we apologize for delay.
Tomorrow, we will update the list again for all submissions from May 20th to end-of-day May 26th.