#KEYMASTER: Can PKCS#10 Handle Post-Quantum Certificates?

In this Keymaster session, Sven Rajala, International PKI Man of Mystery, sits down with David Hook, VP of Software Engineering for Bouncy Castle, to discuss one of the most technical challenges emerging in post-quantum PKI: how to request and issue encryption certificates with modern post-quantum algorithms like ML-KEM (the post-quantum algorithm for key encapsulation mechanisms).

The discussion begins with the limitations of PKCS#10, the long-standing standard for certificate requests. While PKCS#10 works well for traditional algorithms like RSA and ECC, which can both sign, it is not suitable for newer algorithms like ML-KEM that cannot generate signatures. This design assumption in PKCS#10 creates a major barrier to adopting post-quantum cryptography in some PKI workflows.

Watch video on YouTube

David explains that historically, the industry has relied on CRMF (Certificate Request Message Format) to handle proof of possession (PoP) when the key can not sign. Two established CRMF approaches are:

1. Encrypted Certificate – The Certificate Authority (CA) sends back an encrypted certificate, and the requester proves possession by decrypting it and returning a hash.
2. Challenge-Response – The CA sends a challenge, and the requester proves possession by decrypting and responding correctly.

Both methods are supported in Bouncy Castle Java 1.83 and later.

The conversation then turns to the newly published RFC 9883, introducing a Private Key Possession Attribute that extends PKCS#10 to support post-quantum use cases. This allows a PKCS#10 request to include an ML-KEM (encryption) key, where the private key possession is asserted by a signature using a previously issued ML-DSA certificate. This enables the issuance of ML-KEM certificates without changing existing protocols if the new attribute is properly recognized.

The RFC offers a future-proof way to handle post-quantum certificates in standard workflows like CMP, EST, and ACME, enabling interoperability across traditional and PQC environments.

Key takeaways

• PKCS#10 Limitations: It relies on signature-based proof of possession, incompatible with ML-KEM and other encryption-only algorithms.
• CRMF Solutions: Encrypted Certificate and Challenge-Response methods enable proof of possession without signatures. Both are now available in Bouncy Castle.
• RFC 9883 Innovation: Introduces a Private Key Possession Attribute to extend PKCS#10 for post-quantum use cases.
• Hybrid Certificate Support: Combines ML-DSA (signing) and ML-KEM (encryption) keys in a single workflow, bridging classic and PQC ecosystems.
• Bouncy Castle Roadmap: Both methods are supported in Bouncy Castle version 1.83 and later.

Learn more

• RFC 9883
• Download Bouncy Castle Betas
• Download Bouncy Castle