I assume it would be fairly controversial to use MissingNo. for that.
8 Likes
Is there any consideration that there's some specific old version of Android (7.0) that can handle P-256 signatures and not P-384 signatures? And even though P-384 keys are pretty small, yes, P-256 keys are even smaller, and you do seem to be counting every byte (between the truncated hash, using lencr.org, removing an OID).
You could also use some other hash like RIPEMD-160 or one of the BLAKE versions instead, though I can see how truncated SHA-256 might be more "standard".
9 Likes
It's more than just "standard", it's truly standardized by RFC 7093, Section 2! To tell the truth I wasn't even aware of the existence of this RFC before Corey pointed it out on MDSP, but it's a great idea and I was very glad to learn of it!
Because the hash is being used for a non-cryptographic purpose here, really it's just a compression algorithm: take big key and make it small (but still statistically unique). Using SHA-1 for this purpose would be truly fine and good, except for the externality that doing so means crypto libraries have to continue providing SHA-1 support themselves. We'd like to enable the ecosystem to remove SHA-1 support entirely, so moving to something simple and obvious fits the bill best.
The existing E1 and E2 keys would run into this already, so this isn't an issue for this upcoming key ceremony to care about, this is an issue for the "ECDSA For All" change to care about.
8 Likes
A new thing that I learned about the EC curves is that apparently no one is truly using P-384. It's supported in most places, sure, but general maintenance effort appears low. The allmighty OpenSSL doesn't even care enough about it to implement an optimized version for the ubiquitous x86 arch (though an ASM version of P-384 for PPC64 arch was added to OpenSSL recently). Looking in other implementations, we see the same thing: Golang features an optimized version for P-256, like OpenSSL, but not for P-384. Similar stories are found in other crypto libraries (BoringSSL has an ASM version for P-256 in its FIPS module, same for Rust's ring crypto).
Not only makes these non-optimization P-384 fairly slow (its 30x slower compared to P-256 on my machine), but it also makes it feel less maintained and looked at. Some recent research papers on ECDSA implementions barely even look at P-384, but they do always look at P-256.
The Android bug is just another example where some company didn't even test their code with P-384, hence breaking stuff without knowing it.
I wasn't aware of this when the EC hierarchy was first generated in 2020, but since then I've come to dislike the P-384 curve somewhat. It's not the end of the world, so if Let's Encrypt feels that they want to continue going for more bits then go for it, but I personally have begun to think that as long as this curve is so neglected in the industry, it's probably better to stay away from it.
8 Likes
if SKI doesn't need any security resistance, can't one just use b("LE E7") and call it done?
4 Likes
RFC 5280 says
subject key identifiers SHOULD be derived from the public key...
so while the answer is technically "yes", I think it's a stretch to to call a manual mapping of keys to SKIDs "derived from", and it's better to stick to the methods that have been standardized in RFCs 5280 and 7093.
8 Likes
Perhaps, but I thought that this issue was one of the main reasons people might not want all their ECDSA certs signed by a P-384 ECDSA chain, which is why the current system might still be opt-in-only for now (though I may just be wildly speculating). Some people might want an ECDSA chain that only uses P-256 signatures, which they can get from other CAs (I think) but not with the Let's Encrypt current (or these proposed) intermediates.
5 Likes
At the time first posted, having int in the filename and even CN was interesting and appealing for development reasons. A day later, and recalling many of the end-consumer concerns, it's not.
4 Likes
What about using three char naming?:
-
char one: "
R|I"
[Root or Intermediate] -
char two: "
R|E"
[RSA or ECDSA] -
char three: "
0-9A-Z"
[unique identifier]
Some possibilities:
RRR
RED
IE7
IRC
5 Likes
And just to tack onto this a bit, besides the weird broken Android version, some people might want P-256 purely for the performance benefits, along the lines of @Nummer378's analysis that most platforms seem to spend time optimizing it that they haven't for P-384.
I'm not generally the one saying that someone's keys are too long, and I certainly have no objection to P-384 everywhere (and maybe even the ubiquity caused by it being used by Let's Encrypt will incentivize the industry to work on handling it better). I just think that "well, it's so much better than the length of an RSA key, isn't it" isn't a great reason for choosing it. Whereas, something like "the added security of P-384 fits our goals over the expected lifetime better, and we'd really like to use 4096-bit RSA intermediates too for the same reason except that it's just too painful so we're willing to compromise security there even though we don't really want to" would make more sense. Which I think is basically what you're trying to say, but I just personally don't have the knowledge of how much better security vs. poorer performance (both signing & verifying performance) different RSA key sizes vs. different ECDSA sizes are. Maybe I just need to do some research and this is obvious to others.
6 Likes
This stuff is really useful and helpful to the .0001% of users (developers) doing a lot of work with Certificates and Chains or managing the Trust Stores. To everyone else, it's a few extra bytes of unnecessary bandwidth on every request.
The few bytes are not much to most North American and European users with newer hardware and infrastructures, but all that does add up to have tangible impacts on older equipment and congested infrastructures. The impacts of these bytes, chain sizes, and key efficiencies become even more tangible when you start working with in-app browsers. You do feel the performance difference if you're on a 5 year old phone, connected to rural or satellite internet, browsing a webpage through a facebook app that is loading page assets off 10-20 different https sites.
This is why I often prefer using the smallest keys possible.
3 Likes
That actually seem like a good reason for P-384, so as to get those broken Androids replaced.
1 Like
Even if it were for a cryptographic purpose there is the advantage as a defense against Length extension attack - Wikipedia.
Like Length extension attack: SHA-384 has a minor advantage over SHA-512
2 Likes
4 Likes
Skipping root X3 seems reasonable to me. Intermediates should ideally have incrementing numbers and shouldn’t have another 3, at least for a long time.
5 Likes
We can solve that "number 3" issue by using another base and starting from 100 (decimal), maybe. Be it base16 or 64. Base twelve, maybe?
I mean, does it really need to be human readable? If that's a concern then I like actual names, not numbers.
2 Likes
iirc it need to be descriptive enough to know who owns it, so it doesn't add up
we removed those certs from out store:
"root certificate"(publickey:long hex)
2 Likes
I think the theory is that the "Who owns it" is in the Subject (in the O= field), but doesn't need to be in the CN= part of the subject.
How well various software presents the various components of the Subject to users when they need to administrate the certificates somehow is another question entirely, I suppose.
5 Likes
Though now that I look at the Subject of the proposed intermediates again, I'm curious why they need to have a C=US country code, especially if one wants to squeeze out every last byte. Is it just that in theory there could be another Let's Encrypt in some other country?
6 Likes