Post Quantum Crypto

[kuehne-trustable-de]

Are there any plans / schedule to implement PQC algorithms?
Hybrid certificates would be great!

[tashian]

Hi @kuehne-trustable-de, could you share more about your use case for hybrid certs?

[kuehne-trustable-de]

Yes, sure!
I'm consulting organizations with inhouse-PKI and high security requirements. For the promising way to next root key rollover we want to be post-qantum-ready. So the right time is now to evaluate the PKI landscape, select a PKI software, setup a hybrid CA structure and test it with the existing application landscape.
We do expect that the majority of application will !not! be PQ-ready within the next 5 years. So a hybrid certificate approach seems to be a promising way to move forward.

[tashian]

Thanks for the detail. If you're just wanting to have a hybrid root CA certificate, then it should work with step-ca. You would just generate a hybrid root certificate and keys on your own, and configure the CA to use that certificate. Store the root keys offline, they don't need to be part of the step-ca configuration. With any luck, the CA will just ignore the post-quantum properties of the root, and operate just fine.

You would also need to manually sign a regular intermediate CA (not a quantum-ready CA), and configure the CA to sign with it.

[ralienpp]

@tashian, can you elaborate on what type of hybrid certificates are supported, and what algorithms can be used?

Multiple approaches exist and they're at different levels of maturity:

• https://handle.itu.int/11.1002/1000/14033 ITU-T X.509 (aka “Catalyst”, the other public key is baked into the certificate, standardized a couple of years ago)
• https://datatracker.ietf.org/doc/draft-ietf-lamps-cert-binding-for-multi-auth/ (an extension that references the hash of another cert issued to the same entity)
• https://datatracker.ietf.org/doc/draft-lamps-okubo-certdiscovery (use the good old “Subject Information Access” extension to provide a URI to another cert)
• https://datatracker.ietf.org/doc/draft-bonnell-lamps-chameleon-certs/ (so-called “delta certificate” that is used to dynamically compute a related cert)
• https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ (a single keypair and signature, use a composite algorithm that internally consists of 2 elements)
• https://datatracker.ietf.org/doc/draft-sun-lamps-hybrid-scheme/ (new thing from IETF 121, I didn't wrap my mind around it yet)

[maraino]

Currently, it looks like Kyber is going to be included in TLS 1.3. It might come to the Go stdlib once NIST reaches a final spec around 2024. For digital signatures, the situation is a little bit uncertain at the moment, Dilithium or Falcom are leading, but each one has its drawbacks.

We don't have a 100% defined plan for supporting them, but they will be.

[hermanndamon2]

I think it's not easy

[ralienpp]

I'd like to know if the development team has any roadmap updates regarding post-quantum. NIST published the standards for signatures: ML-DSA and SLH-DSA, and ML-KEM (for key encapsulation).

While getting a KEM certificate is tricky, dealing with ML-DSA and SLH-DSA is easier. Open source implementations in Go are available for ML-DSA (cloudflare/circl#480).

[ralienpp]

@tashian In the light of this press release https://smallstep.com/blog/post-quantum-cryptography-at-smallstep/index.html, could you share a rough timeline for when you'd be able to issue PQ certificates? And what type of X.509 hybrid certificates do you plan to support?

[..] stalled because ML-DSA signatures and their public keys remain too large and slow for practical use. [..] plan to add more updates once NIST introduces smaller, faster signatures through its follow-up competition.

For some use-cases ML-DSA and SLH-DSA are good enough as they are, so I believe it makes sense to add support for issuing such certificates without waiting for the follow-up competition. The competition will take years, while the demand for PQ certificates already exists. For example, according to the CNSA 2.0 timeline, we're already at a stage where signing firmware or software with PQ algorithms ought to be a thing. When distributing firmware - the image size dwarfs the size of the certificate, so it would be no issue at all to have large keys and large signatures.

[tashian]

Hi @ralienpp,

Yes I agree that there is demand for PQ certificates, and it's on our roadmap.

We were able to add PQ HKE after it was added to Go's crypto/tls in Go 1.24.

While I can't offer even a rough timeline for PQ certificate support in step-ca right now, our timeline may depend on Go's crypto libraries that we use, so I'd suggest following this umbrella issue.