Digicert already provides the the PQC toolkit to allow the customers to test post-quantum hybrid TLS certificates. Is there a similar initiative for Let's Encrypt? Is there a roadmap for Let's Encrypt to generate post-quantum crypto enabled TLS certificates?
As a reference for anyone curious about this:
https://docs.digicert.com/en/certcentral/certificate-tools/post-quantum-cryptography/pqc-toolkit-setup-guide.html
The toolkit does not seem to be bound to Digicert in anyway.
It's more of a lab testing tool from what I can see.
5 Likes
What algorithms are you asking for?
4 Likes
I think the industry would have to produce a "solution" first.
3 Likes
Precisely. The toolkit appears to be a rebranding of the ISARA Radiateā¢ Quantum-safe Toolkit. This is a patch for OpenSSL to include support for various Post-Quantum candidates.
You can use this tool to generate various (self-signed/untrusted) PQC certificates and then do key exchanges/establishments with them. None of this is bound to any certificate authority.
I am not aware of any. Please note that every publicy trusted certificate authority (such as Let's Encrypt) is bound to the CA/B baseline requirements, which currently does not allow issuance of any post-quantum key type. Any testing officially supported by Let's Encrypt would have to be done using untrusted environments (e.g. Let's Encrypt staging).
A major issue is that there is no full consensus yet about post-quantum algorithms. NIST intends to standardize at least three digitial signature algorithms - which could be used for certificates, plus new key encapsulation methods. There is no definite plan as to where to go, what algorithms should we use, what parameters, how should we mix them with classical crypto? There are lots of ways to mix different algorithms in a PQ certificate chain and it isn't yet (entirely) clear which one is best. PKI as a whole could change drastically.
Thus it feels a bit funny to do "testing" when we've no idea how the PQ certificates are going to look like. The DigiCert guide instructs to generate an eXtended Merkle Signature Scheme root (not a traditional signature scheme), a Dilithium intermediate (NIST intent for standardization) and a Rainbow leaf certificate (NIST PQC round 3 finalist; will not be standardized due to security concerns).
I would love to have a Let's Encrypt staging environment for PQ, but please let's sort out the algorithms before we get ahead of ourselves 
. Any local testing - for example, to test out the above algorithms - can already be done using early-adopter crypto libraries.
9 Likes
PQC draft standards have been released:
Could we explore https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/README.md for allowing users to perform tests in the Let's Encrypt staging environment?
It's unlikely to be any time soon. We try not to let Staging diverge from Production in a meaningful way for very long. Supporting FIPS 204 and FIPS 205 in Boulder before our hardware security modules (and their chain of dependencies) do would require significant differences in the Boulder CA microservice, which is the most security-critical component, and the one we least would want to leave in a divergent state.
While we could technically roll implementations into Boulder CA, or build our own software security module that supported it (along with adding whole new bespoke, internal methods and data structures to PKCS#11), it's a lot of lift for a small team.
PQ is coming. The draft FIPS publications are an excellent next step in the road, but there's a lot more left to standardize even after the primitives are done, and work we do now would be thrown away for the final trusted implementations... and throwing away that much work would be a bitter pill for a team as small as our to swallow, as much as we would like to.
13 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.