I am doing the same since the beginning of ecdsa allow list. Added the account in the allow list, once rcdsa was working i copied the account folder and now every new instance i create i just upload the account folder and issue ecdsa only certs.
1 Like
I wish anyone in the world who was willing to talk about this knew a concrete reason why ECDSA signatures are categorically more or less secure than RSA signatures!
@allanjohn I don't know if it would help anything to point out to your security team that, if someone could break RSA signatures (or keys!) well enough to forge signatures, they could use that capability to forge a certificate for your site using an existing RSA intermediate, whether or not you intentionally choose to use that intermediate at all. This is akin to an old argument for why you're not much better off avoiding Let's Encrypt even if you don't know if you think Let's Encrypt is secure enough!
If you're entirely controlling the environment where the certificates are consumed, you might want to completely remove all of the RSA signature verification code in that environment... but in that case you could also probably fairly easily use a private CA instead of a publicly-trusted one.
3 Likes
Perhaps it's not about where they are now.
But where are expected to be in "five years"...
If you had to keep something encrypted for at least five years [not just encrypt it for 90 days - LOL], then you might imagine that RSA-2048 might not be a great choice for that job.
Given: The Internet in "five years" is an unpredictable place for anyone to fully imagine today.
But the math behind the "power" required to break a specific encryption and the rate that current "power" is increasing [i.e. the time needed to reach that much "power"] is not that much of a wild guess.
Note: "five years" is just an example - their requirement might be even more than that.
1 Like
With the most-used ciphersuites in modern TLS, the signature algorithm from the CA isn't really relevant to long-term confidentiality. If an attacker can't break the signature algorithm at the time that the connection happens, then the connection contents are expected to stay confidential against a future break of that algorithm.
3 Likes
Weâve got an announcement post up so you can read the details now, but we can offer a leaf -> E5..9 -> X1 chain (maybe even as default) without worrying about X2 compatibility or longer chains.
Users who want a pure ecdsa chain can opt pull the leaf -> E5..9 -> X2, or a longer X2 -> X1 cross signed chain if you want clients to be able to use either root.
For a while we might even have a leaf -> E5..9 -> X2 -> X1 -> DST X3 chain, but that depends on how the timing of all this works out. Thatâll certainly never be a default chain.
The âecdsa for allâ announcement will come later, once weâve sorted out new intermediates and the DST X3 change. I think we have an idea for how this will go but no timeline or announcement yet.
6 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.