Post-Quantum Cryptography Keys and Signatures

The following provides an introduction to Post-Quantum Cryptography (PQC) keys and signatures.

Background

Post-quantum cryptography is cryptography that is resistant to the theoretical threat that a cryptographically relevant quantum computer could port. While such a quantum computer does not yet exist, governments and standardization organizations are working towards a migration from classic asymmetric cryptography to new post-quantum cryptography algorithms. The largest actor in this process is the National Institute of Standards and Technology (NIST).

NIST standardized three post-quantum cryptography (PQC) algorithms, FIPS 203 for ML-KEM (derived from CRYSTALS-KYBER), FIPS 204 for ML-DSA (derived from CRYSTALS-Dilithium), and FIPS 205 for SLH-DSA (derived from SPHINCS+).

A fourth digital signature standard FN-DSA (derived from FALCON) will follow. In addition, there are two stateful hash-based signature (SHBS) algorithms standardized in NIST SP800-208 and IETF.

Generated Keys and Certificates

Signature algorithms suitable for a CA are:

ML-DSA, FIPS 204
SLH-DSA, FIPS 205

When generating a CA in EJBCA, multiple keys and certificates can be generated:

A CA signing key pair and certificate
An encryption key pair, used for encrypting key recovery information
An OCSP signer key pair and certificate
A SCEP encryption key pair and certificate

When using PQC keys, the CA signing key pair will be the PQC key type you select when creating the CA. The CA signing certificate will be signed using your selected signature algorithm. The key recovery encryption key pair must still be RSA.

Post-Quantum Algorithms

For a high-level overview of algorithm support across the logical layers involved in EJBCA certificate signing, see Supported Algorithms.

Post-Quantum Cryptography Standards and HSM Compatibility

Enterprise

Use of NIST post-quantum algorithms ML-DSA, SLH-DSA and ML-KEM integrated with HSMs is standardized (without external-mu) in PKCS#11 v3.2. Several REST-based HSMs also support post-quantum algorithms.

Multiple HSMs support ML-DSA and composite keys and signatures. See Interoperability and Certifications for officially supported HSMs and Supported Algorithms for algorithm support in EJBCA across HSMs.

For composite algorithms, note that not all composite algorithm combinations are supported by every HSM. Ensure that both your HSM model and its firmware version support all algorithms included in the selected composite combination.

When using composite signatures, the payload is always hashed before it is sent to the HSM for signing.

Signing large CRLs with PQC algorithms

The new algorithms are generally not hash-and-sign as classic RSA and EC (for example SHA256WithRSA and SHA256WithECDSA) meaning that all data to be signed are sent to the signature function. This can cause problems for signing for example large CRLs using HSMs as the amount of data that can be sent over the network to an HSM is usually limited. Albeit pre-hash versions of ML-DSA and SLH-DSA exist in the FIPS standards IETF have decided to not allow pre-hash ML-DSA and the standard for using SLH-DSA is not yet completed (Feb 2026). See RFC9881 for using ML-DSA, introducing Externalμ-ML-DSA as the selected way to handle signing of large payloads.

Due to the above we recommend early production scale testing of uses cases when using PQC algorithms in order to avoid issues that CRLs can not be created if they grow more than expected. Support for Externalμ-ML-DSA is available with some HSMs but not all so the expected result depends on the exact HSM, and firmware version, being used and the architecture of your solution.

Creating Client Certificates

You can also issue normal requests for client certificates using post-quantum keys.

All certificates signed by a post-quantum CA will naturally use post-quantum signatures, regardless of whether the client keys are RSA, ECDSA, EdDSA, or one of the post-quantum algorithms.

Post-quantum KEM keys cannot be used for signature generation, and therefore, PKCS#10 CSRs that require signature proof of possession (POP) cannot be used. Instead, CRMF messages using the RA Verified POP method can be used. Currently, ML-DSA keys are supported for this purpose. Additionally, for ML-KEM keys, CMP using encrCert POP is supported as of EJBCA 9.1. Furthermore, EJBCA supports the following KEM keys for inclusion in client certificates.

Keys	Comment
ML-KEM-512	FIPS-205 in EJBCA 9.1
ML-KEM-1024	FIPS-205 in EJBCA 9.1

Example CSR Generation

To generate a valid sample CSR for your clients, you can use the EJBCA gencsr CLI command. The following provides an example for generating a CSR with ML-DSA-44:

Bash

bin/ejbca.sh gencsr --keyalg ML-DSA-44 --sigalg ML-DSA-44 --subjectdn "CN=mldsa subject"

Issuing certificates with KEM subject public keys

As KEM keys cannot be used to create signatures, you cannot currently create a PKCS#10 CSR with a KEM public key to request a certificate, since a signature is required for proof of possession (POP). The CRMF CSR format supports alternative POP methods, and you can, for example, use CMP with encrCert POP (see CMP). You can also use other mechanisms that do not require PKCS#10 CSRs to issue certificates with KEM keys, such as CA-generated PEM files or WS API plain public keys.

Example:

ant cmpclient
cd dist/cmpclient
./cmpclient.sh crmf --url http://localhost/ejbca/publicweb/cmp/encrcert --dn "CN=encrCertPOP" --authparam qw --reqnewkeyspec ML-KEM-512 --includepopo --v

Composite Keys

To support the transition from traditional cryptography to post-quantum cryptography, EJBCA supports the use of composite keys, which combine a classical cryptographic key (RSA, ECDSA, or EdDSA) with a post-quantum key (ML-DSA-44, ML-DSA-65, or ML-DSA-87). This approach allows certificates to be protected by both cryptographic components simultaneously during the migration period. For more information, see Managing Crypto Tokens.

For more information, see Post-Quantum Cryptography (PQC) Readiness.