So NIST, Google, Apple, Cloudflare, and others are taking this seriously.
A lot of folks look to LetsEncrypt to be a leader here. The standards may change, but it's prudent to be up-to-date.
Thank you for your consideration for the roadmap!
While you can of course add anything to the roadmap, I find it a bit early for Let's Encrypt to state anything until the cryptographic community has sorted things out a bit more. There's currently no clear guidance on what a Post-Quantum PKI should look like. There's no code in the common HSM modules etc. Let's Encrypt can't just do what they want, there are rules to follow and a hastily written PQ PKI may result in a security disaster.
There's currently a push for PQ-hybrid key exchanges in security protocols (SSH, TLS, IPSec). That's relevant because of store now, decrypt later attacks. It is assumed that there are presently various actors at play who store large quantities of secure sessions (e.g. TLS) to decrypt them at a later point in time using a Quantum Computer. It is therefore relevant to defend against these attacks now, as they're possibly happening right now.
The PKI system on the other hand cannot be attacked after-the-fact, because it provides authentication, which can only be broken live. Therefore, the security community is currently focussed on securing the key exchange. Adding PQ secure authentication will probably happen at a later point. There's still a lot of work to be done on designing this PQ PKI scheme, and it's important that this is done with great care - or you will end up with a system that's not secure at all.
It's important to understand that our security knowledge on the PQ algorithms is still... thin. For instance, NIST was relatively close to standardizing the Rainbow PQ signature scheme, up until this paper came along: Breaking Rainbow Takes a Weekend on a Laptop (The scheme was withdrawn in a coordinated manner shortly before Beullen's work was made public)
"Unfortunately", every publicly trusted CA, thus including Let's Encrypt, needs to abide by the CA/Browser Forum Baseline Requirements. Those BR don't even accept Ed25519 yet, but just the NIST curves..
Until the BR have been changed to allow other algorithms, there's nothing LE can do. Except perhaps suggest a change to the BR. But any CA or browser member of the CA/B Forum can do that..
So while I understand your request, it's not up to Let's Encrypt to suddely implement these things.
Just to put some of what @Nummer378 wrote in context: The Cloudflare research is on Key Agreement within the TLS Handshake; that is independent of x509 Certificates. The NIST research they cited, and later linked to, is also regarding Key Agreement and digest computing within the TLS protocol.
This is all stuff that will eventually be implemented by the servers/gateways/CDNs that ISRG runs the LetsEncrypt service on. This stuff is all independent of the Certificates themselves.
While some of the new research deals with calculating digests, LetsEncrypt's digests are communicated through TLS encrypted payloads between the server and client - so there isn't much of an immediate concern there. The current weak spots in the ecosystem, and the immediate target of improvements, are all in the key exchanges.
In terms of changes to Certificates (such as key types), that is driven by the CA/B forum baseline requirements. Extensions or changes to the ACME protocol would require a mix of IETF support and CA/B Forum acceptance. TLDR on that is that we're not able to see any change on those things unless there is hotfix to a compromise, or several members make a coordinated push to fasttrack a new standard. LetsEncrypt staff have made it clear they want to fasttrack new PQ standards once the ecosystem is more stable - things are simply at a place now where there is a 99.9% chance all their work would be experimental R&D that is immediately obsoleted.
This is a common source of user confusion. To add to the good information from @Nummer378 and @jvanasco, here is a practical view for immediate use:
You can and should deploy post-quantum encryption on your website today. I am currently working on that (and on a website about post-quantum encryption). “All” you need is to link your webserver or TLS terminator with an SSL/TLS library that supports post-quantum KEX (key exchange).
BoringSSL has had full support since “Implement X25519MLKEM768 for TLS” authored 2024-08-23, committed 2024-08-27:
My preliminary testing shows that BoringSSL at its current HEAD seems to support both standard ML-KEM as SSL_GROUP_X25519_MLKEM768 in the source, and the draft SSL_GROUP_X25519_KYBER768_DRAFT00 that has some support from many web browsers in the wild. I haven’t yet tried this on a functioning webserver—only in the bssl shell tool. I am busy patching BoringSSL to set policies that prefer or enforce PQ-KEX, among other things. (Beware that BoringSSL disobeys the old-style OpenSSL cipher/KEX preferences for TLS 1.3; it’s non-obvious unless you read the source. I should have a fix for this on Github soon, if I stop writing all this stuff.)
At the time of this writing 2025-01-24, this OpenSSL issue is still open:
For this reason, I am switching to BoringSSL with my own patches.
To round out this quick review of how you can use post-quantum encryption right now, GnuPG has supported hybrid PQC with NIST standard ML-KEM since GnuPG v2.5.1 released 2024-09-12—only 30 days after NIST published the final FIPS-203. You need that for your personal communications. And you should set this in your OpenSSH configs on both client and server:
Omit the latter two if you have OpenSSH below v9.9. If needed temporarily to allow other KEX for sites that don’t yet support any of these, use Host blocks. OpenSSH has supported PQ-KEX since 2022.
All of this pertains only to post-quantum encryption. As Nummber said, this will protect data intercepted for future decryption, whether by governments or by unofficial criminals. There is absolutely no security need for post-quantum signatures in TLS at this time: Large quantum computers do not yet exist, and a potential future attacker cannot go back in time to forge signatures to tamper with TLS connections in the present.
And also: browsers would also need to support any post-quantum key exchange, not just the webserver.