It's ok. There are other CAs now. We can set high expectations and push boundaries.
6 Likes
Actually there's another real advantage of serving the X2-by-X1 cross-signed root-cert for some time; it allows for legacy browsers to cache and trust X2, which will ease a later transition to a pure X2-based chain. Not just for that same website serving it, but for all websites visited by the same browsers that once saw and cached the cross-signed root.
It's also an argument to generate the cross-signed root with a sufficiently long lifetime.
5 Likes
Unfortunately I don't believe this is true. Truly old browsers don't cache intermediates, and more modern ones which do put strict limits on that cache -- Chrome, for example, only caches certs for half an hour. So getting X2-by-X1 into browser caches wouldn't have a meaningful impact on those browsers trusting X2-self-signed later on.
3 Likes
ISRG Root X2 being introduced into Android 14 is quite the problem for services with a lot of Android clients.. They wouldn't be able to switch to the ISRG Root X2-only chain for a long time to come.
What kind of usage does Let's Encrypt expect for the ISRG Root X2-only chain? Because when assuming generic webservices will have a significant amount of customers with Android <14, I don't really see any real usage for this short chain.
4 Likes
Yep. Thankfully, Android 14 also made the trust store updateable without requiring a whole OS update, so future roots should propagate across the Android ecosystem much faster.
Relatively low; that's why it's offered as the alternate, not the default chain. But it can still be an improvement for services which control the client side of their connection, such as API servers, IoT fleets, enterprises, and more.
It's also worth noting that ECDSA keys currently make up a tiny portion of our end-entity issuance. The vast majority of clients are still submitting RSA pubkeys in their CSRs, and will receive issuance from R10/R11 with no need to worry about alternate chains.
4 Likes
"Truly old" browsers don't trust X1 yet either, so they're out of scope for this discussion. Here we're looking at "relatively recent but not the latest" browsers and/or operating systems, which trust X1 but not yet X2.
Interesting note about Chrome. I'm sure Firefox caches intermediate certificates for much longer. Is this behaviour documented somewhere? Are there any recommendations or best practices around it?
3 Likes
Thankfully indeed, but that's of much use for Android pre-14, which still makes up 83.49 % of the Android ecosystem (source).
But the X2-by-X1 cross-sign would enable more users to offer a ECDSA only chain. Sure it would add some bytes to the handshake, but it would give services more flexibility: offer the regular chain with their RSA certificates and offer the longer chain with their ECDSA certificates.
Hm, probably due to large providers using only RSA? As Certbot has switched to ECDSA by default in their v2 release.
3 Likes
For new keypairs, but not for renewals of existing certs. So it will take some time.
5 Likes
That's true indeed. 
3 Likes
In my opinion, the entire value proposition of ECDSA-only validation chains is their small size.
At a given security level, ECDSA offers faster key generation, smaller key sizes, and smaller signature sizes than RSA. However, the tradeoff is that in turn ECDSA has slower signature validation than RSA at the same security level.
So the goal of an ECDSA-only chain can't be faster validation. Instead, the primary goal is smaller validation: fewer bytes exchanged on the wire during the TLS handshake, which in turn can result in faster connection startup.
So offering ECDSA-only validation with the caveat that it comes with a huge extra RSA-signed cert attached (every single time, to every single client, because the server has no way to know whether that client trusts X2 or not) has very little value, IMO.
David Benjamin has an IETF draft called Trust Expressions that would allow TLS clients and servers to negotiate what roots they trust, and allow the server to provide the smallest chain that the client will trust. But until then, I think the cost of sending a whole extra-large chain on every single handshake outweighs the speculative benefits of ECDSA-only validation of a subset of that chain.
8 Likes
@aarongable But what's the size difference between a chain chaining up to X1, which is already the big RSA certificate (thus a large signature on the cross-signed E{5..9}, versus the long chain, via X2-signed-by-X1 up to X1? This moves the large RSA signature to the X2 ECDSA cross-signed cert and replaces the large cross-signed with RSA E5 with the small ECDSA signed E5.
If I do the math using DER files with a random example cert signed by E1 (signature should be same size as E5s signature):
leaf <- E5 cross-signed by X1: 919 + 1115 = 2034 bytes
leaf <- E5 signed by X2 <- X2 signed by E1: 919 + 696 + 1124 = 2739.
That's not THAT much larger in size, just 705 bytes or 35 % extra. The amount of TCP packages required for the handshake might not even increase (the small chain is already more than the regular MTU)..
5 Likes
I don't know how long Firefox might cache intermediates that it doesn't otherwise know about, but it does preload all intermediates directly from CCADB regularly:
6 Likes
Thanks for doing the math! But I'm not sure that I'd classify 35% as "not THAT much". 
Recall that trying to save ~800 bytes per TLS handshake was one of the main reasons we introduced ECDSA intermediates in the first place.
3 Likes
Well, that's true indeed 
I'd still like to at least have the option to generate my own long chain anyway though 
3 Likes
I have the feeling that you have the skills to script it if you really need it. 
2 Likes
Problem is that the current cross-sign is expiring in 2025. Unfortunately I don't have access to a large, working quantum computer to hack the X1 public key into its private key component to sign a new X2 cross-sign myself 
6 Likes
FWIW, I've done a bit of testing in this area before. It has been at least 7 years since any of it was relevant though.
My interest in this, and the issues I found, was based on the performance of HTTPS on embedded browsers – like when you click a link in a iOS or Android Facebook app. Up until the 2015-2017 period, there was a significant and tangible hit to performance on many devices, especially legacy models. This has not been a problem since 2017, as earlier devices and operating systems have aged out.
This appeared to be connected to the size of certs/chains impacting memory, and not the validation or decryption. These performance hits were not negligible, due to a mix of hardware and how the embedded browsers managed memory and connections. All these things have improved since then.
3 Likes
We've decided to defer taking any action to renew the X2-by-X1 cross-sign for now. We will revisit in 2025 to make a decision on whether or not to renew it, once everyone has some experience with the new ECDSA chains.
11 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.