The term on this page
- PQCpost-quantum cryptography
- algorithms that run on ordinary computers and are believed to resist quantum attack
Also mentioned
ECDHECDHElliptic Curve Diffie-HellmanElliptic Curve Diffie-Hellman, a key-exchange method using elliptic-curve mathematics to establish a shared secret with smaller keys than classical Diffie-Hellman.Read the full entry (new tab), ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), PKIPKIpublic key infrastructurePublic Key Infrastructure, the framework of certificate authorities, certificates, and policies that binds public keys to identities and enables trust in TLS, code signing, and email.Read the full entry (new tab) are defined in the glossary.
Read this first
A post-quantum certificate test must prove more than parser acceptance. Check the algorithm identifier and absent parameters, the permitted key-usage bits, the exact public-key bytes, all private-key representations your systems exchange, and the full import and export path across every runtime, HSM, CA and recovery tool. Preserve one valid and several deliberately invalid artifacts for each boundary. A certificate that one library can read is not yet a migration-ready credential.
Post-quantum PKI work often starts with a reassuring demo: generate an ML-KEM or ML-DSA key, issue a certificate, and parse it successfully. That is useful, but it proves only one path through one tool. The migration risk sits in the boundaries around it: object identifiers, ASN.1 parameters, key-usage policy, private-key representation, hardware import rules, backup and restore, and older systems that do not recognize the new algorithm.
The cryptographic inventory should therefore record formats and consumers, not just algorithm names. A useful entry says which system generates a key, which container carries it, which component stores it, which CA issues the certificate, which relying parties parse it, and which recovery tool must be able to restore it. That turns a vague post-quantum migration task into a finite set of acceptance tests.
Separate the certificate from the private-key container
An X.509 certificate carries a public key in SubjectPublicKeyInfo. A private key normally moves in a separate container such as the OneAsymmetricKey structure defined by RFC 5958. These objects can fail independently. A relying party may parse the certificate while an HSM rejects the corresponding private key, or a runtime may import a seed representation while a recovery tool expects an expanded key.
| Artifact | What to verify | Typical hidden failure |
|---|---|---|
| Certificate public key | OID, absent parameters, exact public-key length and key-usage bits | A parser accepts an OID but policy allows the wrong operation |
| Certificate signature | Issuer algorithm, signature encoding and chain validation | A PQC subject key is authenticated by a chain the relying party cannot validate |
| Private-key container | Algorithm identifier, seed or expanded representation, optional public key and attributes | Generation succeeds but import, backup or rollback fails |
| Protocol use | The application actually uses the certified key for its permitted purpose | A valid certificate is installed but the protocol selects another key or algorithm |
Keep these artifacts under separate identifiers in the test record. A single pass or fail label hides which layer broke. It also makes rollback dangerous: teams can restore an old certificate without realizing that the new private-key representation is still present, or restore a key while the application continues to select a different credential.
Pin the ML-KEM certificate profile
RFC 9935 defines the X.509 algorithm identifiers for ML-KEM-512, ML-KEM-768 and ML-KEM-1024. In SubjectPublicKeyInfo, the algorithm parameters are absent and the public key is carried without another ASN.1 wrapping layer. If the keyUsage extension is present, keyEncipherment must be its only asserted use.
That gives an acceptance test with useful negative cases. Start with a known-good certificate for the chosen parameter set. Then add a NULL parameter, wrap the public key in an extra OCTET STRING, change its length, set digitalSignature, or set more than one key-usage bit. The issuer and relying party should reject artifacts that violate the profile, rather than normalizing them silently.
ML-KEM is not a signing key
An ML-KEM certificate can carry a key used to establish a shared secret. It does not make that key suitable for certificate signatures or application signatures. Test the subject key purpose and the issuer's signature algorithm as separate properties.
The certificate chain also needs an explicit security policy. RFC 9935 specifies the subject public-key format, not a universal rule for the strength of every issuer above it. Record which classical or post-quantum signature authenticates the leaf, how the chain maps to the PQC cryptographic floor, and which relying parties can validate that path.
Pin the ML-DSA certificate profile
RFC 9881 defines ML-DSA-44, ML-DSA-65 and ML-DSA-87 for X.509 certificates and revocation lists. Its permitted certificate key usages are digitalSignature, nonRepudiation, keyCertSign and cRLSign. It also requires algorithm parameters to be absent and defines exact public-key and signature encodings.
Build separate fixtures for leaf signing, CA signing and revocation-list signing. A certificate-authority path should prove that keyCertSign is present when required and that an end-entity profile does not receive CA privileges by accident. Test malformed public-key lengths, forbidden parameters, truncated signatures and signatures created with the wrong parameter set. A parser returning an object is not the same as a verifier enforcing the profile.
For protocol teams, keep certificate validation separate from protocol negotiation. A runtime can understand an ML-DSA certificate while the relevant TLS, CMS, S/MIME or SSH profile remains unsupported or unfinished. Use the end-to-end hybrid TLS method when the credential is part of a TLS trial, and record the certificate and CertificateVerify algorithms independently from the key exchange.
Exercise every private-key representation
The standardized ML-KEM and ML-DSA private-key containers allow three representations: a seed, an expanded key, or both. RFC 9935 recommends the 64-byte ML-KEM seed for compact storage. RFC 9881 recommends the 32-byte ML-DSA seed. Both specifications warn that expansion is one way: after an implementation discards the seed, it cannot reconstruct the seed from the expanded key.
| Representation | Benefit | Acceptance evidence |
|---|---|---|
| Seed | Compact and can deterministically derive the public and expanded keys | Import, derivation, backup and restore work inside the approved boundary |
| Expanded key | Can serve implementations that do not expose seed import | Length, integrity checks, public-key recovery and export policy are enforced |
| Both | Bridges seed-aware and expanded-key consumers | The recipient regenerates the expanded value and rejects a mismatch |
Do not infer the representation from total length. Both RFCs assign different ASN.1 tags to seed, expandedKey and both, and tell parsers to use those tags. Include a fixture with a valid length but the wrong tag, plus a both-form fixture whose seed and expanded value disagree. The recipient should reject the inconsistent object if it performs the specified consistency check.
For ML-KEM expanded keys, RFC 9935 also carries the FIPS 203 hash check into the import path. Treat that check as an acceptance criterion for every component that accepts an expanded key. A migration that verifies key generation but skips import validation leaves a different, and often less reviewed, security boundary untested.
Test the entire ownership path
A realistic trial crosses more than one implementation. The CA may run one library, the HSM another, the application a third, and the disaster-recovery process an offline tool that is upgraded on a different schedule. List each handoff and run the same artifact corpus through it. The crypto-agility implementation guide can attach an owner, change mechanism and verification step to each dependency.
- Generate the key in every supported origin, including software, HSM and secure element paths.
- Export only the representations policy allows, then confirm prohibited exports fail clearly.
- Import into every current and rollback version that may receive the object.
- Issue, renew, revoke and replace the certificate through the real CA workflow.
- Restore from backup into a clean environment and prove the restored key matches the certificate.
- Attempt mismatched OIDs, parameter sets, key usages, public keys, seeds and expanded keys.
- Record the exact software, firmware, provider, OID, container form and artifact hash for each result.
Run the matrix before changing the default representation. Java 27, for example, changed the default encoding for newly generated ML-KEM and ML-DSA private keys to a seed form while documenting compatibility considerations for older Java releases. The general lesson is broader than one runtime: defaults are part of the migration surface, and mixed-version fleets need explicit import and rollback tests.
Composite certificates do not remove compatibility work
The current IETF composite ML-KEM draft packages ML-KEM with RSA-OAEP, ECDH, X25519 or X448 behind one algorithm identifier. Its purpose is to make a hybrid look like one KEM to a protocol. That is protocol compatibility, not automatic application compatibility. The draft says only upgraded systems understand its new OIDs.
Composite decapsulation can also need the traditional public key for the combiner. Depending on the component and container, an implementation may derive it, extract it, fetch it from the certificate, or carry it in OneAsymmetricKey. Add that retrieval path to the test plan. A private key that imports successfully but cannot supply the required public key is not usable evidence.
Choose the profile before choosing fixtures
First decide whether the system is testing standalone ML-KEM, standalone ML-DSA, or a named composite construction. Pin the RFC or exact Internet-Draft revision and parameter set. Fixtures built for one profile are not proof for another.
The minimum acceptance record
A useful record fits on one page: artifact hash, profile and revision, algorithm OID, parameters state, key usage, public-key and signature lengths, private-key representation, producer, consumer, import and export result, consistency-check result, protocol result, test time and owner. Keep the malformed fixtures beside it so the negative controls can be rerun after upgrades.
This method does not prove that every implementation is free of side channels or that every future protocol will accept the credential. It proves a narrower and valuable claim: the formats, policies and ownership paths required by this migration behaved as specified at a known point in time. Combine it with an implementation audit for parser and key-handling risk, and conformance testing for algorithm behavior.
References
- RFC 9935: Algorithm Identifiers for ML-KEM in X.509. ML-KEM public-key encoding, key usage, private-key representations and consistency checks.
- RFC 9881: Algorithm Identifiers for ML-DSA in X.509. ML-DSA certificate, signature, key-usage and private-key encoding rules.
- RFC 5958: Asymmetric Key Packages. OneAsymmetricKey container for private and public key material and attributes.
- RFC 5280: Internet X.509 PKI Certificate and CRL Profile. Base certificate, extension and path-validation profile.
- FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. ML-KEM key generation, decapsulation key validation and parameter sets.
- FIPS 204: Module-Lattice-Based Digital Signature Standard. ML-DSA key generation, signatures and parameter sets.
- draft-ietf-lamps-pq-composite-kem-23. Work in progress defining composite ML-KEM identifiers, serialization and operational considerations.
Where this goes next