Composite ML-DSA certificates: are they ready for VPNs?

A composite ML-DSA certificate is an X.509 certificate in which one public key and one signature value each contain two parts: a post-quantum ML-DSA component (FIPS 204) and a classical RSA, ECDSA or EdDSA component. Protocols handle the pair as a single atomic algorithm, and verification only succeeds if both component signatures are valid.

For operators of OT and critical infrastructure, the format raises practical questions. VPN gateways authenticate tunnels between substations, plants, cloud workloads and remote engineers, and those certificates often stay in service for many years. This article covers the standardisation status, the security properties, the effect on handshake size, and how European and US authorities differ on the subject.

What is a composite ML-DSA certificate and how does it differ from a pure ML-DSA certificate?

A pure ML-DSA certificate carries only an ML-DSA key and signature. A composite certificate binds ML-DSA to a traditional algorithm, so anyone forging it would have to break both.

The specification, draft-ietf-lamps-pq-composite-sigs from the IETF LAMPS Working Group, defines combinations of ML-DSA with RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519 and Ed448. The design goal is what the draft calls “protocol backwards compatibility”. The certificate presents one public key and one signature value, so protocols such as TLS or IKEv2 can treat it like any other signature algorithm without being redesigned to understand hybrids.

The terminology comes from RFC 9794 (June 2025), which defines a PQ/T hybrid scheme as a multi-algorithm scheme with at least one post-quantum and at least one traditional component. Under that terminology, “composite” is one way to build such a hybrid: the components are merged into one data structure instead of being carried separately.

The signing process is more than two signatures placed side by side. Each composite algorithm identifier has its own label, and the draft passes that label into ML-DSA as the context string. This domain separation stops an attacker from removing one component and presenting the other as a valid standalone signature.

Are composite ML-DSA certificates standardized by the IETF yet?

Not as an RFC at the time of writing. The IETF Datatracker lists draft-ietf-lamps-pq-composite-sigs at revision -19, still an active Internet-Draft.

The document has gone through many revisions since it was an individual draft, and several of them changed object identifiers or the signature construction in ways that broke compatibility. Revision -04, for example, issued new prototype OIDs because earlier changes made it incompatible with -03. Any composite certificate issued from a pre-RFC draft should be treated as a test artefact.

The TLS side is less mature. draft-reddy-tls-composite-mldsa, which defines how composite ML-DSA is negotiated in TLS 1.3 through the signature_algorithms and signature_algorithms_cert extensions, is still an individual draft, and its code points are still marked TBD. Pure ML-DSA, by contrast, has been a final NIST standard since FIPS 204 was published in August 2024.

Do composite certificates stay secure if RSA or ECDSA is broken by a quantum computer?

Yes. A composite signature only verifies if both components verify, so it stays secure as long as ML-DSA does. The reverse also applies: it is not weakened if a flaw turns up in ML-DSA or in a particular ML-DSA implementation.

The draft says composite algorithms retain some security even if one of their component algorithms is broken. That is the main reason to use them during a transition. If a cryptographically relevant quantum computer breaks ECDSA P-256, the composite certificate falls back to the security of ML-DSA-65. If someone finds a lattice cryptanalysis result or a side-channel bug in an ML-DSA library, the classical component still protects authentication.

There is one condition. The draft notes that once an algorithm is known to be broken, cryptographic policy should forbid it for single-algorithm use. Hybrids that include it can stay in service. In practice, the gateways must be configured to reject plain RSA or ECDSA certificates once that point is reached. A composite certificate adds no protection if the peer still accepts a classical-only certificate for the same identity.

Signatures are not exposed to harvest-now-decrypt-later attacks the way key exchange is. A forged signature only matters while a quantum computer exists to produce it. The reason to start early anyway is the slow replacement cycle of OT equipment and PKI hierarchies.

How large are composite ML-DSA certificates and will they break IKEv2 or TLS handshakes?

Composite keys and signatures are only slightly larger than pure ML-DSA, but both are far larger than classical certificates. They will not break modern handshakes, but IKEv2 needs fragmentation support and constrained links need testing.

Most of the extra size comes from moving to ML-DSA at all. Adding an ECDSA component costs only around a hundred bytes on top of that.

Impact on IKEv2

In IKEv2, certificates and the AUTH signature travel in the IKE_AUTH exchange, which normally runs over UDP. A certificate with a composite public key and a composite CA signature is already several times larger than a typical Ethernet MTU. A full chain with intermediate certificates is larger still. Without IKEv2 message fragmentation (RFC 7383), the IP layer fragments these messages, and fragmented UDP is often dropped by firewalls, NAT devices and some carrier networks. Practical steps:

• Confirm that both peers support RFC 7383 and that it is enabled, not just available.
• Keep chains short: a dedicated VPN issuing CA directly under the root avoids an extra intermediate.
• Where peers are preconfigured, consider not sending the full chain in every exchange, using the certificate encodings that RFC 7296 allows.
• Test over the real paths: cellular backhaul, satellite and narrowband links to remote OT sites behave differently from a lab LAN.

Impact on TLS

TLS runs over TCP, so a large certificate flight is segmented automatically and will not break the handshake. The cost is extra latency: a large server flight can take an additional round trip before the client receives it. On high-latency links this is noticeable but rarely a functional problem.

Should VPN gateways use composite certificates or separate classical and post-quantum certificates?

Where both ends of the tunnel are under one organisation’s control, composite certificates usually give clearer security semantics. Separate certificates are easier to introduce gradually but need strict policy to avoid falling to the weaker algorithm.

The IETF PQUIP work on constrained devices notes that non-composite hybrids, with both signatures carried separately, are simple to implement and fit existing architectures. For a VPN the main risk is policy drift. Unless every gateway requires both certificates on every tunnel, a separate-certificate deployment can quietly end up relying on the classical certificate alone. A composite certificate removes that option, because a gateway cannot accept half of it.

A practical split for OT operators: use composite certificates for tunnels between sites you control, where you can coordinate firmware and CA upgrades, and keep pure ML-DSA-87 for any links that must follow CNSA 2.0.

Authentication is also only half of the problem. Gateways such as Quantum Network’s QPN protect confidentiality with a hybrid key agreement, combining a classical part with ML-KEM (FIPS 203) into one session key, and both handshakes renew every two minutes. Certificate authentication is a separate layer that has to be planned on its own timeline.

Do BSI, ANSSI and NSA CNSA 2.0 accept composite signatures for certification?

The European agencies and the NSA take opposite positions. BSI and ANSSI recommend hybrid post-quantum cryptography. The NSA’s CNSA 2.0 profiles require pure ML-DSA-87 and reject other signature methods.

BSI and ANSSI

BSI’s guidance, quoted in IETF draft-vaira-pquip-pqc-use-cases, says that “quantum computer-resistant methods should not be used alone - at least in a transitional period - but only in hybrid mode”. A joint position paper by ANSSI, BSI, the Netherlands’ NLNCSA and the Swedish National Communications Security Authority states that “the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions”. That sentence is about key establishment, but it reflects the same hybrid-first approach. The composite signature draft cites both BSI and ANSSI as agencies whose approach composite schemes are compatible with.

A general recommendation is not the same as certification. Formal approval in national evaluation schemes is granted per product and per evaluation, so operators should check the current requirements of the relevant scheme instead of assuming that a composite algorithm is approved.

NSA CNSA 2.0

The draft CNSA 2.0 profiles written by NSA authors are explicit. The certificate management profile says: “Signatures MUST be ML-DSA-87.” The draft CNSA 2.0 IPsec profile requires ML-DSA-87 for IKEv2 authentication and tells the relying party to return AUTHENTICATION_FAILED for any other method. Under that profile, a composite certificate presents a different algorithm identifier and would be rejected.

How should OT operators prepare for composite certificates now?

Start with inventory and testing, not production certificates. The standards are close to final but not finished, and the hardest constraints in OT are usually firmware, HSMs and link capacity.

• Map which policy applies to which tunnels: European guidance, CNSA 2.0, or both. This decides between composite and pure ML-DSA.
• Check your HSM and CA roadmap for support of FIPS 204 and the composite OIDs. Composite private keys hold two key parts, which affects key ceremonies and backups.
• Measure the IKE_AUTH size on your most constrained links with test chains at ML-DSA-65 and ML-DSA-87 strength.
• Write the policy now that rejects classical-only certificates once composite ones are deployed, so the migration does not leave a weaker fallback in place.
• Prioritise key exchange first: hybrid ML-KEM protects recorded traffic today, while composite authentication addresses a later threat.