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).