up:: Migration Architecture MOC

Composite Certificates

A composite certificate is a single X.509 certificate that carries both a classical public key (such as ECDSA or RSA) and a post-quantum public key (such as ML-DSA) bound together as one algorithm, signed twice, so the certificate validates only when both signatures verify. It’s the format-level way to move a PKI through the post-quantum transition without a flag day: a verifier that understands the composite format gets post-quantum protection, while the certificate still fits the same X.509 slot every relying party already parses. The IETF’s standardized version is Composite ML-DSA, which the LAMPS working group defines for exactly this X.509 migration job.

Source: J. Gray, M. Ounsworth, S. Fluhrer et al., “Composite ML-DSA for use in X.509 Public Key Infrastructure and CMS,” IETF LAMPS WG, draft-ietf-lamps-pq-composite-sigs (v19, 21 April 2026, in RFC Editor queue).

The short version:

• A composite certificate binds two keys and two signatures, one classical and one post-quantum, into a single certificate that presents as one algorithm with one identifier.
• It validates only when both component signatures verify, so a forger has to defeat the classical algorithm and the post-quantum algorithm at the same time.
• Its whole reason to exist is that a standard X.509 certificate holds exactly one public key and one signature, so carrying two algorithms needs a new format, and composite is the format that keeps the protocol untouched.
• The IETF standard is Composite ML-DSA (LAMPS working group), pairing ML-DSA with RSA-PSS, RSA-PKCS1, ECDSA, Ed25519, or Ed448, treated as a single atomic algorithm at the protocol level.
• It differs from running two parallel certificates (the dual approach) by hiding the “require both” logic inside the certificate format, and from Cross-Certification, which links two separate certificate authorities rather than combining algorithms in one certificate.
• Composite is a bridge for the migration window, not a destination. It costs certificate size and needs verifier support, and the classical half is quantum-vulnerable by definition.

Picture a diploma that has to carry two official seals, an old wax seal every clerk in the country already recognizes, and a new holographic seal only the upgraded offices can read. The document is printed once, on one sheet, and both seals are pressed onto it. An upgraded office checks both seals and only honors the diploma if both are genuine. An old office that has never seen the hologram can still read the wax seal and process the paper the way it always has. A forger who has learned to fake wax still gets caught, because he can’t reproduce the hologram, and a forger who cracks the hologram still gets caught, because the wax is wrong. One sheet of paper, two independent proofs of authenticity, and the harder-to-fake proof keeps working even while the old offices catch up.

What is a composite certificate?

A composite certificate is a certificate-format pattern, not a new cryptographic algorithm. It takes two signature algorithms from different families, a classical one and a post-quantum one, and packages their public keys and their signatures inside one X.509 certificate that the rest of the system handles as though it were a single algorithm. RFC 9794, the IETF’s terminology standard for post-quantum/traditional hybrids, defines a composite element as one that “incorporates multiple component cryptographic elements of the same type… such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements.” That single-interface property is the entire trick: two algorithms go in, one algorithm comes out to every piece of software that touches the certificate.

Source: F. Driscoll, M. Parsons, B. Hale, “Terminology for Post-Quantum Traditional Hybrid Schemes,” IETF, RFC 9794, June 2025.

To see why this needs a special format, look at what a normal certificate can hold. RFC 5280, the profile every public certificate authority follows, defines the field that carries the key as a single structure with room for exactly one algorithm and one key:

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING  }

One AlgorithmIdentifier, one subjectPublicKey, and elsewhere in the certificate one signatureAlgorithm and one signatureValue. A standard X.509 certificate binds one public key with one algorithm and carries one signature, full stop. A composite certificate works by making that single algorithm slot point to a composite algorithm identifier, and making that one key and one signature each be a structured pair of a classical and a post-quantum component underneath.

Source: D. Cooper, S. Santesson, S. Farrell et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF, RFC 5280, §4.1.2.7, May 2008.

The IETF has narrowed this from a general idea into a concrete standard, Composite ML-DSA, produced by the LAMPS working group (Limited Additional Mechanisms for PKIX and SMIME). It pairs the post-quantum signature ML-DSA with one traditional signature algorithm, drawn from RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, or Ed448, and registers each pairing under its own combined object identifier so a mismatched combination can’t be substituted. As of April 2026 the draft is at version 19 and has been handed to the RFC Editor for publication, so the format is stabilizing into a real standard rather than an experiment.

Source: draft-ietf-lamps-pq-composite-sigs (component algorithms and combined OIDs).

Why does PKI need composite certificates to migrate?

PKI needs composite certificates because the certificate ecosystem can’t switch to post-quantum signatures on a single coordinated day, and a standard certificate forces an all-or-nothing choice. Billions of deployed clients, servers, operating-system trust stores, and embedded validators check certificates using classical algorithms today. If a certificate authority issued a post-quantum-only certificate, every one of those relying parties would have to understand ML-DSA before the certificate could be trusted anywhere, so no authority can move first. That’s the chicken-and-egg problem that stalls unilateral PKI migration.

Composite breaks the deadlock by letting one certificate serve two populations at once. A relying party that understands the composite format validates both algorithms and gets genuine post-quantum protection. The certificate authority issues that one certificate now, before the whole ecosystem has upgraded, and the population of composite-aware verifiers grows underneath it over time. This is the defense-in-depth argument as well as the compatibility one: because both signatures must verify, the certificate is forgeable only by an adversary who breaks the classical algorithm and the post-quantum algorithm together, which is a far higher bar than breaking either alone.

The urgency comes from where certificates live in the risk model. Certificate signatures protect trust and integrity, which means the threat is PKI Collapse: once a cryptographically relevant quantum computer can run Shor’s algorithm, it forges the classical signatures that anchor the entire web of trust, and an attacker can mint certificates that chain to a real root. Long-lived certificates make this pressing today, because a root certificate authority key or a multi-year certificate issued now may still be in service when that machine arrives. Composite lets those long-lived certificates start carrying a quantum-resistant signature immediately, so the trust anchor is already hardened by the time the classical half stops being safe.

How does a composite certificate actually work?

A composite certificate works by binding two component keys under one composite identifier, signing the certificate content with both private keys, and requiring both signatures to verify. Walking it through end to end:

1. Key material. The subject holds two key pairs, one classical (for example ECDSA on P-256) and one post-quantum (for example ML-DSA-65). Both public keys are serialized together into the certificate’s single public-key field as a composite public key, and the certificate’s algorithm identifier names the specific composite combination rather than either component alone.
2. Signing. The certificate authority signs the same certificate content with both of its private keys. In Composite ML-DSA the two signatures are computed over a single combined message representative, M' = Prefix || Label || len(ctx) || ctx || PH(M), where the fixed prefix string CompositeAlgorithmSignatures2025 and an algorithm-specific label bind the signature to the composite combination so a component signature can’t be lifted out and reused on its own. The resulting classical and post-quantum signatures are concatenated into the certificate’s single signature value.
3. Verifying. A composite-aware verifier splits the composite structure, checks both component signatures, and accepts the certificate only when both verify. If either component fails, the whole certificate is rejected.
4. Chain propagation. For end-to-end post-quantum protection, every certificate in the trust chain, from the root through any intermediates to the end-entity certificate, has to be composite. A composite end-entity certificate that chains up to a classical-only intermediate leaves the chain’s trust anchor forgeable by a quantum adversary, so the post-quantum guarantee is only as strong as the weakest link in the chain.

Source: draft-ietf-lamps-pq-composite-sigs, message-representative construction and combined signature serialization.

The security property is where composite earns its keep, and the standard states it precisely: “Composite ML-DSA will be EUF-CMA secure if at least one of its component algorithms is EUF-CMA secure and the pre-hashed message representative PH is collision resistant.” In plain terms, the certificate stays unforgeable as long as one of the two algorithms is still standing, which is the same “secure if either half holds” guarantee that hybrid key exchange gives for confidentiality, applied here to authentication. The draft also flags an honest caveat: composite ML-DSA is proven EUF-CMA (existential unforgeability), a slightly weaker property than pure ML-DSA’s SUF-CMA, so it isn’t a free upgrade in every dimension.

Source: draft-ietf-lamps-pq-composite-sigs, security considerations (EUF-CMA guarantee).

The reason this design keeps the protocol untouched is the single-atomic-algorithm property. Because the composite presents “a single public key and signature value such that it can be treated as a single atomic algorithm at the protocol level,” a protocol like X.509, CMS, or PKCS#10 handles it the way it handles any other signature algorithm, with no change to the message flow. RFC 9794 draws the general line this way: in the composite approach “changes are primarily made to the formats of the cryptographic elements, while the protocol fields and message flow remain largely unchanged,” whereas a non-composite approach changes the protocol fields or flow instead. Composite pushes all the new complexity down into the certificate format and the crypto library, and leaves the wire protocol alone.

Source: draft-ietf-lamps-pq-composite-sigs (atomic-algorithm property); RFC 9794 (composite vs non-composite).

How is a composite certificate different from dual certificates and cross-certification?

The difference is about where the “require both algorithms” logic lives, and it separates three approaches people mix up. All three help a PKI carry more than one algorithm, and they solve genuinely different problems.

RFC 9794 draws the first line cleanly: a post-quantum/traditional hybrid certificate can carry its component public keys “as a composite public key or as individual component public keys.” That’s the split between composite and dual. A composite certificate fuses the two algorithms into one certificate under one identifier, so the library sees a single algorithm and the “both must verify” rule is baked into the format. A dual approach (also called parallel, and closely related to dual signatures) instead carries two separate certificates or two separate signatures side by side, one per algorithm, which keeps each algorithm fully legible to old software but pushes the decision of whether to require both out to every verifier’s policy.

Source: RFC 9794, definition of a PQ/T hybrid certificate.

Cross-Certification is a different axis entirely. It doesn’t combine algorithms inside a certificate at all; it creates a trust relationship between two separate certificate authorities, so a relying party that trusts one authority’s root can validate certificates issued under the other. Cross-certification is a PKI topology tool for bridging trust domains, and a certificate authority could run a post-quantum root and cross-certify it with a classical root as one migration path, which is a separate strategy from putting two algorithms in one certificate.

Approach	What it combines	Where “require both” lives	Old software sees	Migration role
Composite certificate	Two algorithms fused in one certificate, one OID	Inside the certificate format and crypto library	One (unknown) composite algorithm	Format-level bridge that keeps the protocol unchanged
Dual / parallel certificates	Two separate certificates or signatures, one per algorithm	In each verifier’s policy	Each algorithm as its own normal certificate	Keeps each algorithm legible; burden on verifiers
Cross-Certification	Two separate certificate authorities, linked by trust	Not applicable, it’s a trust bridge, not a multi-algorithm cert	A normal single-algorithm chain	Topology bridge between trust domains
Hybrid key exchange	Two KEMs combined for a session key	In the key-derivation step	A negotiated key-exchange group	Protects session confidentiality rather than certificate identity

The last row matters because it’s the most common confusion. Hybrid key exchange and composite certificates are both “run classical and post-quantum together,” but they protect different things. Hybrid key exchange combines two KEMs to protect the confidentiality of a session, so recorded traffic can’t be decrypted later. Composite certificates combine two signatures to protect identity and trust, so an adversary can’t forge who you’re talking to. A full migration needs both, on their own timelines, because a connection using hybrid key exchange over a classically-signed certificate is still trusting a quantum-forgeable identity.

What are the tradeoffs of composite certificates?

The costs are real and they cluster in three places: size, verifier support, and the fact that composite is temporary by design.

1. Size. A composite certificate carries a full post-quantum public key and a full post-quantum signature on top of the classical ones, and those post-quantum values are large. ML-DSA keys and signatures run to the kilobyte scale against tens of bytes for an elliptic-curve equivalent, so a composite certificate is substantially bigger than a classical one, and the effect compounds across a chain where the root, intermediate, and end-entity certificate are all composite. That inflation lands in the TLS handshake, where a fatter certificate chain slows the connection and can strain memory-constrained or embedded validators.
2. Verifier support. Composite only delivers its security if the relying party actually validates both components, and a composite certificate handed to a validator that doesn’t understand the format gets you classical security at best. Support in mainstream TLS libraries, operating-system trust stores, and application validators is still maturing, so a deployment has to confirm that the verifiers on the path genuinely parse and check the composite structure rather than assuming they do.
3. It’s a bridge, not a destination. The classical component in a composite certificate is exactly the part a quantum computer forges, so it contributes nothing against a CRQC once one exists. Composite earns its complexity during the window when verifiers are split and the post-quantum algorithms are still young, and the endgame is post-quantum-only certificates once the ecosystem has caught up. A composite certificate that never plans its retirement quietly becomes permanent overhead and hides an unfinished migration behind a reassuring format.

There’s also a discovery tradeoff worth naming for anyone building a crypto inventory. Composite certificates are identifiable by their combined OIDs and their larger-than-normal size, but standard certificate-inspection tools that predate the format may parse them incorrectly or skip them, which creates blind spots in an inventory. “We have post-quantum-capable TLS” is not the same statement as “our certificates are composite,” because a common configuration adds hybrid key exchange without touching the certificate signatures at all.

Common misconceptions

• “A composite certificate is just two certificates stapled together.” It’s one certificate under one composite algorithm identifier, with the two component keys and signatures fused so the crypto library treats them as a single atomic algorithm. Carrying two separate certificates is the dual or parallel approach, which is a different pattern with the “require both” rule living in verifier policy instead of the format.
• “Composite protects data confidentiality.” Composite certificates protect signatures, meaning identity and trust and integrity, so they defend against a forged certificate under PKI Collapse. Confidentiality against harvest-now-decrypt-later is a job for key establishment, handled by hybrid key exchange rather than by certificates.
• “If my end-entity certificate is composite, my chain is quantum-safe.” The whole chain has to be composite. A composite end-entity certificate chained to a classical-only intermediate or root still has a quantum-forgeable trust anchor, so the post-quantum protection is only as strong as the weakest certificate in the chain.
• “Composite gives strictly more security than pure ML-DSA.” It gives redundancy, so it stays secure if either algorithm holds, which is valuable during the transition. On the formal property it’s proven EUF-CMA rather than the stronger SUF-CMA that pure ML-DSA achieves, so the tradeoff is hedged robustness against a slightly weaker unforgeability guarantee.
• “Composite certificates are the permanent post-quantum PKI.” They’re a transitional bridge sized for the window where verifiers are split. The classical half is quantum-vulnerable by definition, so a composite deployment with no plan to move to post-quantum-only certificates is carrying dead weight and masking an unfinished migration.
• “Post-quantum-capable TLS means composite certificates are deployed.” Those are different layers. Most early post-quantum TLS deployments add hybrid key exchange for confidentiality while the certificates stay classically signed, so having one says nothing about having the other.

Questions people ask

How is a composite certificate different from a hybrid one? In practice the terms overlap, and “hybrid certificate” is often used loosely for any certificate carrying both a classical and a post-quantum algorithm. The precise standards term is a PQ/T hybrid certificate, and RFC 9794 splits it into two forms: composite, where the component keys are fused into one composite public key, and the individual-component form, where they’re carried separately. Composite is the specific fused variant.

Do all the certificates in my chain have to be composite? For end-to-end post-quantum protection, yes. A composite certificate that chains up to a classical-only intermediate or root leaves the trust anchor forgeable by a quantum adversary, so the chain is only as quantum-safe as its weakest certificate. Partial deployment still has compatibility value, but it doesn’t deliver the full guarantee.

Which algorithms go into a Composite ML-DSA certificate? Composite ML-DSA pairs the post-quantum signature ML-DSA with exactly one traditional signature algorithm, chosen from RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, or Ed448, and each pairing has its own registered combined object identifier so combinations can’t be mismatched.

Is Composite ML-DSA a finished standard yet? It’s a mature IETF draft rather than a published RFC. As of April 2026 draft-ietf-lamps-pq-composite-sigs is at version 19 and has been submitted to the RFC Editor queue for publication, so the format is stabilizing but the RFC number isn’t final. Library support is still catching up to the specification.

How much bigger is a composite certificate? Meaningfully, because it adds a full ML-DSA public key and signature, which are kilobyte-scale, on top of the classical values that are tens of bytes. The exact inflation depends on the specific ML-DSA parameter set and classical partner, and it compounds across a chain, so latency-sensitive TLS surfaces should size the whole chain against handshake limits before deploying.

When should the classical half come out? When post-quantum-only certificates are practical across the relying parties that matter and the migration is genuinely complete. The classical component is quantum-vulnerable by definition, so once a cryptographically relevant quantum computer is a near-term concern and verifiers support post-quantum algorithms directly, the composite certificate has done its bridging job and should retire rather than persist as overhead.

How do I tell a composite certificate apart from a normal one? By its algorithm identifier and its size. A composite certificate names a combined composite OID in the algorithm field rather than a single classical algorithm, and it’s visibly larger because it carries two keys and two signatures. Inspection tooling that predates the format may misread or skip it, which is a real gap when you’re inventorying what cryptography you actually have.

---

Everything here is the map, given freely. When your team needs its own certificate authorities, trust chains, and validators assessed for a composite rollout that actually delivers the guarantee and plans its retirement, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.