I meanwhile filled out the allow-list form which is mentioned e.g. here ECDSA availability in production environment twice (6-8 weeks ago and last week) and wonder if processing is paused or delayed.
Would be great to have some feedback as I'd really like to participate.
By the way, does the LE team has statistics about the lead time for the processing of the ECDSA allow list? Similarly as with the rate limit form, quite often there's a thread opened on the Community. The ECDSA allow list suggests a daily review with weekly processing (including a disclaimer). I'm asking as perhaps expectations might be better managed if the form resembles the actual processing more closely. If the processing is actually daily with some exceptions you can disregard my question.
Just out of interest, why is there an allow list for ECDSA? I just wondered if there was a documented reason for not opening that up to just anyone (perhaps it's a considered a breaking change if LE starts giving you a full EC chain and in the past it would have been RSA even with and EC key?)
Thanks, I'm fairly Windows-centric so I rarely think about the legacy chain now (because it just doesn't really work on Windows regardless). So it's because users currently with an EC key could/would get a breaking change to their chain.
It's also my understanding that there's some specific old version of Android where the TLS client stack supports P-256 signatures but not P-384 signatures, so you can use a P-256 ECDSA key for your certificate on the RSA chain, but it would break for those users if signed with the P-384-based ECDSA chain.
Basically, it's not quite ready to be the default state of things just yet.
Which literally means you cannot use a certificate from E1, per §22.214.171.124.2 of the CA/B baseline requirements.
(It says you have to sign using ECDSA with sha-384. You could sign using ECDSA with sha-256 if you had a P-256 intermediate, but E1 is P-384. And it has to be exactly that hash function, you can't use sha-384 with a P-256 intermediate.)
There are documented (implicit) reasons, such as those stated here.
Essentially, the allow-list is/was meant to keep the number of early adopters relatively small, while ECDSA is being rolled out. This enables finding potential issues, avoiding potential mass-revocation events until everything is in good condition. The chain also only unfolds its full potential after ISRG Root X2 is in trust stores, so we're waiting for that. Now ISRG Root X2 has already reached a number of trust stores*, so I expect that the allow list will be removed somewhere this year. The numbers of accounts on the list is also growing steadily, so all should be good.
*ISRG Root X2 is currently in the following root programs/trust stores:
Mozilla: ISRG Root X2 is included in trust stores as of Firefox 97
Google: The Chrome Root Store proposal was updated on 2022-02-16 and now includes ISRG Root X2. AFAIK the Chrome Root Store is not yet used in Chrome though.
Windows: The Microsoft Root Program includes ISRG Root X2 since last year.
(Or in other words: The two programs still missing are Apple and Oracle)
Yes that's right. That's actually Android 7.0 which is not that old (the Android world is horribly fragmented though...). However I don't think LE caters for that version anyway. That Android version doesn't have ISRG Root X1 in its trust store either, so it won't work without the compatibility extension (which is not offered by LE for full-ECDA chains) anyhow.
(The technical issue seemed to be that whoever managed the builder configuration for that version at Google (accidentally?) configured BoringSSL to only build with support for P-256 and nothing else, probably due to a misconfiguration of the FIPS-module. This was apparently only fixed with the 7.1 release - which contained quite a number of important bugfixes as 7.0 was a mess anyway. However some vendors decided that 7.1 was a major release (new features in 7.1), and due to policy 7.1 wasn't rolled out for "EOL" devices, so some got stuck on that buggy version)
You're talking about what hash function to use with a given curve, but that's actually not the issue. I believe the BoringSSL version handles SHA384 just fine. It's just the curve that won't work. The algorithm specified ecdsaWithSHA384 is actually curve-agnostic, but yes it's used together with P-384.