up:: Migration Architecture MOC

Composite vs Dual vs Cross-Certification

Composite certificates, dual signatures and cross-certification are the three structural patterns for moving a PKI through the post-quantum transition. They are routinely presented as competing choices and they operate at different layers, which is why a real migration commonly deploys all three.

Composite fuses a classical and a post-quantum algorithm into a single certificate that validates only as a unit. Dual keeps the 2 signatures separable so old verifiers keep working. Cross-certification bridges 2 certificate-authority hierarchies so a new post-quantum root inherits trust from an established classical one.

The short version:

• They operate at different layers. Composite and dual work inside a certificate. Cross-certification works between CA hierarchies, and it combines no algorithms at all.
• Composite enforces “both must hold” in the format. A single algorithm identifier, one fused signature, accepted only when both component signatures verify. An un-upgraded verifier cannot validate it at all, and that refusal is the design working.
• Dual buys backward compatibility and moves enforcement to the verifier. Each signature stays in its normal single-algorithm format, so legacy software validates the classical half and skips the post-quantum one.
• That enforcement gap has been measured, and it is total. Across 24 stack-and-scheme combinations, none required both signatures by default, and RFC 9763 related certificates were accepted classically by all 8 stacks tested.
• All three are transitional. Every one of them keeps a classical component that a quantum computer eventually forges, so each needs a retirement plan rather than becoming the destination.

Three ways to get a new kind of official seal accepted. The first prints both the old and new seals as a single combined mark, so any office that honors it has verified both, and offices that have never seen the combined mark hand the document back. The second prints the two seals side by side, so old offices stamp on the strength of the one they recognize and never look at the other. The third leaves the seals alone entirely and instead has the long-established seal office write a letter vouching that the new seal office is legitimate, so documents carrying only the new seal are honored by anyone who already trusts the old office.

What is the difference between composite, dual and cross-certification?

The difference is where the work happens. Composite and dual both address a single certificate carrying 2 algorithms, and they differ on whether those algorithms are fused or separable. Cross-certification does not touch algorithms inside a certificate at all: it addresses whether a relying party trusts the authority that issued the certificate, by having a certificate authority vouch for a different one.

The consequence is that composite and dual are genuine alternatives to each other, while cross-certification is complementary to both. A post-quantum root can issue composite certificates and still need a cross-certificate from a classical root so relying parties validate them before trust stores update.

What is a composite certificate?

A composite certificate is a single X.509 certificate carrying both a classical public key and a post-quantum public key bound together as a single algorithm, signed twice, validating only when both signatures verify. RFC 9794 defines a composite element as one incorporating multiple component elements “such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements.”

It needs a special format because RFC 5280’s SubjectPublicKeyInfo holds exactly a single algorithm identifier and key, with a single signature algorithm and signature elsewhere in the certificate. Composite works by pointing that single algorithm slot at a composite identifier whose key and signature are each a structured pair underneath.

The IETF specification is Composite ML-DSA from the LAMPS working group, approved as a Proposed Standard and sitting in the RFC Editor queue, pairing ML-DSA with RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519 or Ed448, registering each pairing under its own combined object identifier so a mismatched combination cannot be substituted.

Source: F. Driscoll, M. Parsons, B. Hale, “Terminology for Post-Quantum Traditional Hybrid Schemes,” RFC 9794, June 2025; M. Ounsworth, J. Gray, M. Pala et al., “Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure,” draft-ietf-lamps-pq-composite-sigs, v19, 21 April 2026, in the RFC Editor queue.

What is a dual signature?

A dual signature signs the same data independently with a classical and a post-quantum algorithm and carries the two signatures as separate, individually checkable objects. RFC 9794 calls this the non-composite branch, where “the formats of the component cryptographic elements are the same as when they are used as part of a single-algorithm scheme.”

It comes in two standardized shapes:

1. Two separate certificates linked to one owner. RFC 9763 defines a relatedCertRequest CSR attribute and a RelatedCertificate X.509 extension that binds a new certificate to a previously issued one, carrying a hash of the related certificate and a signature made with its private key. The extension “SHOULD NOT be marked critical,” so software that does not understand it validates the certificate normally.
2. A single certificate carrying a second signature in extensions. ITU-T X.509 (2019) defines three non-critical extensions, subjectAltPublicKeyInfo, altSignatureAlgorithm and altSignatureValue, so a single certificate carries a post-quantum key and signature alongside its classical ones. Vendors named this pattern “catalyst” certificates.

Source: A. Becker, R. Guthrie, M. Jenkins, “Related Certificates for Use in Multiple Authentications within a Protocol,” RFC 9763, June 2025; ITU-T Recommendation X.509 (10/2019), clause 7.2.2.

What is cross-certification?

Cross-certification is a certificate authority issuing a certificate for a different authority’s public key, creating a trust bridge between two separate PKI hierarchies. RFC 5280 §3.2 defines cross-certificates as CA certificates in which the issuer and subject are different entities.

Its post-quantum job is direct: an existing classical root that is already widely trusted vouches for a new post-quantum root, so post-quantum certificates validate through an anchor relying parties already hold while their trust stores update on a slower schedule. A bridge CA is a specialized use, a hub cross-certifying with one CA in each participating PKI so trust relationships grow linearly rather than exponentially, with the U.S. Federal Bridge CA as the canonical example.

Source: D. Cooper, S. Santesson, S. Farrell et al., RFC 5280, §3.2, May 2008.

Composite vs dual vs cross-certification at a glance

Dimension	Composite certificate	Dual signature	Cross-certification
Layer it operates at	Inside a single certificate	Inside a single certificate, or across 2 linked certificates	Between CA hierarchies
What it combines	2 algorithms fused into 1 signature under 1 identifier	2 algorithms kept as separable signatures	Nothing. It bridges trust rather than combining algorithms
What a verifier checks	Splits the object and verifies both components, accepting only if both pass	Each signature on its own, with policy deciding whether both are required	The chain, tracing from a trusted anchor across the bridge
Backward compatibility	None. An unknown composite identifier fails on old verifiers	Full. Each signature is an ordinary single-algorithm signature	Full. Relying parties need no change at all
Enforces “both must hold”	Yes, in the format	Only if the verifier is configured to require both	Not applicable
Standards status	Composite ML-DSA, a mature IETF draft in the RFC Editor queue	RFC 9763 published for related certificates; ITU-T X.509 (2019) for alternative-signature extensions	RFC 5280, long established
Naming settled	Yes	No. “Dual” is a working name; RFC 9794 says non-composite and parallel	Yes
The classical component	Fused into the certificate	Carried alongside	Signs the bridge certificate itself
What a quantum computer forges	Neither component alone suffices, so the composite holds while either algorithm holds	Whatever the verifier actually checked, which measurement shows is the classical half	The bridge, since it is signed with the classical CA’s classical key
Primary use	A clean single-slot certificate with format-enforced strength	Keeping verifiers you do not control working during the transition	Letting a new post-quantum root inherit existing trust
Retirement trigger	When post-quantum-only certificates are practical	When verifiers validate post-quantum signatures directly	When the new root is natively in trust stores

How do they actually differ?

1. The “require both” decision lives in different places. Composite bakes it into the format, so a crypto library treats the certificate as a single atomic algorithm and rejects it unless both components verify. Dual leaves it to verifier policy, because two separable signatures can each be checked alone. Cross-certification does not raise the question, since it combines no algorithms.

2. They trade compatibility against enforcement in opposite directions. Composite gives up legibility to un-upgraded verifiers and gains a guarantee. Dual gives up the guarantee and gains full backward compatibility. That is the same trade seen from either side, and it is why the two coexist rather than one winning.

3. Cross-certification solves a problem the other two cannot touch. A composite or dual certificate still has to chain to an anchor the relying party trusts. If a new post-quantum root is not in the trust store, no amount of algorithm combining inside the leaf helps, and a cross-certificate from an established root is what closes that gap.

4. The ITU-T alternative-signature form is explicitly not a both-must-hold proof. ITU-T X.509 (2019) specifies that only one of the two keys is used at a time, so that form is a migration mechanism rather than a combined-strength guarantee on its own.

5. Their failure modes differ in visibility. A composite certificate presented to an un-upgraded verifier fails loudly and visibly. A dual certificate presented to the same verifier succeeds quietly on the classical half, which looks identical to success and is the more dangerous outcome.

The measurement that changes how dual should be read

The compatibility that makes dual attractive is the same property that makes it quiet, and that has now been measured directly. Kim et al. drove three separable hybrid designs, the ITU-T alternative-signature form, the delta-certificate form and RFC 9763 related certificates, against 8 path-validation stacks built on 7 independent codebases.

Across 24 stack-and-scheme combinations, 19 accepted on the classical path without ever checking the post-quantum signature, 4 recognized the post-quantum material without letting it affect the verdict, 1 rejected an unsupported structure, and none required both signatures by default. RFC 9763 related certificates were unanimous, with all 8 stacks accepting classically. Four of those stacks demonstrably verify ML-DSA signatures elsewhere along a certification path, so this is a policy gap rather than an algorithm-support gap.

The property to require, and to test for, is that the post-quantum signature be outcome-bearing: a failure in it has to be able to turn an otherwise-successful validation into a rejection. The test is direct. Invalidate the post-quantum signature on a certificate in a controlled environment and see whether the verdict changes. If the verifier still accepts, the deployment is dual on the wire and classical in the decision.

Source: T. Kim, B. Chung, K. Kim, Y. Kang, “Classical Acceptance Is Not Hybrid Authentication: Validation Policy and Lifecycle Management of Hybrid X.509 Certificates in Deployed Open-Source Stacks,” arXiv:2607.20800, Table IV, v3, 12 August 2026 (preprint; reproducibility package at Zenodo 10.5281/zenodo.21452130).

Where do they agree?

1. All three are transitional by design. Each keeps a classical component that a CRQC eventually forges, so each earns its place only during the window when the ecosystem is split and each needs a dated retirement plan.

2. All three carry the post-quantum size cost. A composite or dual certificate carries a full post-quantum key and signature in addition to the classical ones, and a cross-certified chain adds another certificate to validate. That weight lands on parsers, trust stores and transport limits regardless of the pattern.

3. None of them makes a chain quantum-safe on its own. Protection is only as strong as the weakest certificate in the chain, so a hybrid leaf that chains through a classical-only intermediate or root still hangs from a quantum-forgeable anchor.

4. All three address authenticity rather than confidentiality. Signatures defend against forgery, so none of them protects recorded traffic from later decryption. That is the job of hybrid key exchange on a separate timeline.

5. All three are made cheaper by crypto-agility. Designing so the algorithm can change without rebuilding the surrounding infrastructure is what turns each retirement into a configuration change rather than a rebuild.

When is each the right answer?

Composite fits when you control the verifiers. A closed environment where composite-aware libraries can be deployed gets a single certificate slot and a format-enforced guarantee that an attacker must defeat both algorithms, without depending on every verifier’s policy to require both.

Dual fits when backward compatibility with verifiers you do not control is the binding constraint. If the population checking your signatures includes old browsers, embedded validators, operating-system trust stores or partner systems that will not learn a new composite identifier on your timeline, dual keeps all of them working. The measurement above means the post-quantum half should be treated as unenforced until tested rather than assumed protective.

Cross-certification fits whenever a new root needs to be trusted before trust stores update, which is nearly every real post-quantum PKI migration. It is the pattern that makes the other two deployable at all, and it is why the three are usually found together rather than chosen between.

Common misconceptions

1. “Composite and dual are the same thing.” They are opposite designs. Composite fuses both algorithms into one signature object that validates as a unit, and dual keeps two separable signatures each legible on its own. RFC 9794 names them the composite and non-composite branches.

2. “Two signatures means an attacker has to break both.” Only if the verifier requires both, and measurement across 8 path-validation stacks found none requiring both by default. With separable signatures that decision lives in verifier policy rather than in the format.

3. “Cross-certification is an alternative to composite or dual.” It solves a different problem, bridging CA hierarchies rather than combining algorithms, and a migration commonly needs it alongside whichever certificate pattern it chooses.

4. “A composite certificate failing on old verifiers is a bug.” That refusal is the design working. It prevents anyone being waved through on the classical half while everyone downstream assumes the post-quantum half was checked.

5. “These protect data from being decrypted later.” Signatures protect authenticity and integrity, so all three defend against forgery rather than against harvest-now-decrypt-later decryption.

6. “A hybrid leaf certificate makes the chain quantum-safe.” The chain is only as strong as its weakest certificate, and a hybrid leaf chaining through a classical-only intermediate or root still depends on a quantum-forgeable anchor.

Questions people ask

Which one should I deploy? Favor composite when you own the verifiers and want the format to enforce both algorithms, and dual when the verifiers are ones you cannot upgrade on your own timeline. Cross-certification is usually needed regardless, to make a new post-quantum root trusted while trust stores catch up.

Does dual give me “secure if either algorithm holds”? Composite gives that guarantee inside the format. Dual gives it only when the verifier is configured to require both signatures, and no measured default configuration does.

How do I test whether my hybrid deployment is real? Invalidate the post-quantum signature on a certificate in a controlled environment and check whether the verdict changes. If validation still succeeds, the post-quantum signature is not outcome-bearing and the deployment is classical in the decision.

Is there a finished standard for any of these? Cross-certification is settled in RFC 5280. Composite ML-DSA is a mature IETF draft in the RFC Editor queue. Dual is assembled from pieces, with RFC 9794 for terminology and RFC 9763 for related certificates, plus ITU-T X.509 (2019) for the alternative-signature extensions.

Why is “dual” not a standardized term? There is no single unified RFC by that name. RFC 9794 calls the umbrella idea non-composite and lists parallel signatures as one construction, so precision means citing the specific mechanism rather than a blanket standard.

Do these add much size? Yes. Each carries a full post-quantum key and signature alongside the classical ones, and post-quantum values are large, so handshakes and certificate chains inflate under any of the patterns.

When does the classical component come out? When post-quantum-only signing is practical across the verifiers that matter and the migration is genuinely complete. The classical half is quantum-forgeable by definition, so it should retire rather than linger as permanent overhead.

Can I use more than one at once? Yes, and most large migrations do. Composite or dual handles the certificate contents, and cross-certification handles the trust hierarchy, so they compose rather than compete.

What does a cross-certificate cost me at quantum time? The bridge is signed with the classical CA’s classical key, so a quantum computer can eventually forge it. It is a transitional measure that retires once the new root is natively trusted.

---

The map is free and I keep it that way. When the question becomes which of these patterns belongs where across a real certificate estate, and whether the guarantee actually holds in the verifiers that matter, that’s the work I do at LaMarr Labs.

Go deeper

• Composite Certificates, Dual Signatures and Cross-Certification for each pattern in full
• The Ignore-or-Reject Question for whether a verifier ignores or rejects a field it does not understand
• Certificate Lifecycle Management for PQC for operating these at scale
• Public Key Infrastructure (PKI) and X.509 Certificate for the substrate
• PKI Collapse for what these patterns are defending against
• Migration Architecture MOC for the whole migration-pattern picture

Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs.