up:: Migration Architecture MOC

Dual Signatures

A dual signature, also called a dual-algorithm or parallel signature, is a transitional pattern in which the same data is signed independently by a classical algorithm (such as RSA or ECDSA) and a post-quantum algorithm (such as ML-DSA), and the two signatures are carried as separate, individually checkable objects rather than fused into one. That separability is the whole point: a verifier that only understands the classical algorithm validates the classical signature and ignores the rest, while a verifier that understands the post-quantum algorithm can check that one too, so old and new software coexist during the migration window without a coordinated cutover. It is the same “run classical and post-quantum together” idea behind hybrid key exchange, applied to the authentication side, and it is the deliberate opposite of a composite certificate, which fuses both algorithms into a single signature object under one identifier.

The short version:

1. A dual signature signs the same message or certificate twice, once with a classical algorithm and once with a post-quantum one, and keeps the two signatures separable instead of merged.
2. Its defining advantage is backward compatibility. Because each signature stays in its normal single-algorithm format, legacy software validates the classical half and simply skips the post-quantum half it can’t parse.
3. It comes in two shapes: two separate certificates linked to the same owner (standardized in PKI by RFC 9763), or one certificate carrying a second key and signature in non-critical X.509 extensions (the ITU-T “catalyst” style).
4. Whether you get “must break both algorithms” strength depends on the verifier’s policy, because with two separable signatures the decision to require both lives with the verifier, not inside the format.
5. The terminology isn’t fully settled. RFC 9794 calls the umbrella idea “non-composite” and lists “parallel signatures” as one construction; “dual signatures” and “dual certificates” are the common informal names for the same family.

Picture a treaty written out twice on the same page, once in Latin and once in a newer language only the modern offices read, each version carrying its own official seal. A clerk who reads only Latin verifies the Latin seal and honors the document, never needing the second column. A modern office reads both and can insist that both seals check out before it trusts the page. One document, two independent proofs, and each reader validates the one they can actually read. A composite certificate instead blends both languages into a single hybrid script that only the upgraded offices can read at all, which is the trade the two designs make against each other.

What is a dual signature?

A dual signature is a way of attaching two independent digital signatures, from two different algorithm families, to the same piece of signed data during the post-quantum transition. Each signature is a normal digital signature in its own right: a classical one produced by RSA, ECDSA, or another traditional scheme, and a post-quantum one produced by a standardized algorithm like ML-DSA. The two are transported side by side so they can be checked separately, which is exactly what distinguishes this family from a composite construction that presents both algorithms as one atomic signature.

RFC 9794, the IETF’s terminology standard for post-quantum/traditional hybrids, is the anchor for placing this in the standards landscape. It splits hybrid constructions into composite (exposed as “a singular interface of the same type as the component algorithms”) and non-composite (where “the formats of the component cryptographic elements are the same as when they are used as part of a single-algorithm scheme”). Dual signatures are the non-composite branch. The same document notes that a hybrid signature can be built several ways and names “parallel signatures, composite signatures, or nested signatures” as examples, so “parallel” is the RFC’s word for what practitioners usually call dual.

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

The reason this matters is where signatures sit in the risk model. Certificate and code signatures protect trust and integrity, so the quantum threat to them is forgery: once a cryptographically relevant quantum computer runs Shor’s algorithm against a classical public key, it recovers the private key and can forge anything that key signed, up to and including forging a certificate authority. Dual signatures let a signer start attaching a post-quantum signature now, alongside the classical one every existing verifier still relies on, so the migration begins before the whole ecosystem can validate post-quantum algorithms directly.

How does a dual signature actually work?

A dual signature works by signing the same content twice with two different private keys and carrying both signatures in a form each is legible on its own. There are two standardized-or-specified shapes, and they differ mainly in whether the two signatures live in two certificates or one.

1. Two separate certificates, linked to one owner. The signer holds two end-entity certificates, one classical and one post-quantum, each a completely ordinary single-algorithm certificate. To prove the two belong to the same entity, RFC 9763 defines a Certificate Signing Request attribute, relatedCertRequest, and an X.509 certificate extension, RelatedCertificate, that binds a new certificate to a previously issued one by carrying a hash of the related certificate and a signature made with its private key. A protocol can then request both signatures and confirm, through that link, that both came from the same party. RFC 9763’s own framing is that it lets users “employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms,” and its RelatedCertificate extension “SHOULD NOT be marked critical,” so software that doesn’t understand it validates the certificate normally.

Source: A. Becker, R. Guthrie, M. Jenkins, “Related Certificates for Use in Multiple Authentications within a Protocol,” IETF, RFC 9763, June 2025.

2. One certificate carrying a second signature in extensions. ITU-T X.509 (2019) defines three non-critical extensions, subjectAltPublicKeyInfo (an alternative public key), altSignatureAlgorithm (the alternative algorithm), and altSignatureValue (the alternative signature), so a single certificate can carry a post-quantum key and signature alongside its primary classical ones. The alternative signature is computed over the certificate’s contents excluding the primary signature and the altSignatureValue field itself. Because the extensions are non-critical, a legacy verifier reads the certificate, checks the primary classical signature, and never touches the alternative one, while a post-quantum-aware verifier additionally recomputes and checks altSignatureValue. This is the pattern vendors named “catalyst” certificates.

Source: ITU-T Recommendation X.509 (10/2019), “Information technology, Open Systems Interconnection, The Directory, Public-key and attribute certificate frameworks,” clause 7.2.2 (alternative signature construction).

An honest precision point separates these from a both-must-hold guarantee. ITU-T X.509 (2019) specifies that only one of the two keys is used at a time, so the alternative-signature form is a migration mechanism, not by itself a proof that combines the strength of both algorithms. You get the “an attacker must defeat both” property only when a verifier or protocol actually requires both signatures to validate, which is a policy the verifier enforces rather than something the format guarantees. That is the structural difference from composite, where “require both” is baked into the single fused object.

How is it different from a composite certificate?

The difference is where the “require both algorithms” logic lives, and it drives every other trade between the two. A composite certificate fuses a classical and a post-quantum key and signature into one object under one algorithm identifier, so a crypto library treats it as a single atomic algorithm and accepts it only when both component signatures verify. That gives a clean single-slot certificate and a built-in “secure as long as at least one algorithm holds” guarantee, at the cost of legibility to any verifier that doesn’t recognize the composite identifier. A dual signature instead keeps the two signatures separable in their normal formats. It gives up the single-object neatness and wins backward compatibility, because old software validates the classical signature it already understands and skips the post-quantum one.

Approach	What is signed	How a verifier checks it	Backward compatibility	Standards status
Single-algorithm signature	The data signed once, by one algorithm	Verify the one signature	Baseline (nothing new)	Long-established (FIPS 204, RSA/ECDSA in FIPS 186-5)
Composite certificate	The data signed by both keys, fused into one signature value under one OID	Split the object, verify both components, accept only if both pass	None; an unknown composite OID fails on old verifiers	Composite ML-DSA, a mature IETF draft in the RFC Editor queue
Dual, two certificates	The data signed independently by two separate certificates’ keys	Verify each certificate and signature on its own; policy decides whether both are required	Full; each is a normal single-algorithm certificate	Published RFC 9763 links the two certificates to one owner
Dual, alternative-signature extensions	The certificate content signed twice, the second in non-critical extensions	Legacy verifier checks the primary signature only; a PQ-aware verifier also checks altSignatureValue	Full; non-critical extensions are ignored by legacy clients	Specified in ITU-T X.509 (2019); the mirroring IETF draft expired

Sources: F. Driscoll, M. Parsons, B. Hale, RFC 9794, June 2025 (composite vs non-composite).

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

The two are complements rather than rivals, and a real migration can mix them. Composite is the tidy long-term shape once verifiers broadly understand the format; dual is the compatibility bridge that keeps working while much of the installed base still speaks only classical algorithms. Both sit alongside cross-certification, which solves a third problem entirely by linking two certificate authorities rather than combining or duplicating algorithms inside the certificates they issue.

Is this a finished standard yet?

Not as one unified thing, and it is worth being precise about what is settled and what is not. There is no single published “dual signatures” RFC the way composite signatures have a dedicated specification heading toward publication. Instead, the dual family is assembled from pieces at different maturity levels. The umbrella terminology is standardized: RFC 9794 is a published RFC that defines composite versus non-composite and names parallel signatures as a construction. The two-certificate mechanism is standardized: RFC 9763 is a published RFC that provides the certificate-linking machinery for non-composite hybrid authentication. The single-certificate alternative-signature mechanism is standardized in ITU-T X.509 (2019), an ITU-T recommendation, though the IETF draft that mirrored it into the LAMPS profile (draft-truskovsky-lamps-pq-hybrid-x509) expired without becoming an RFC.

The naming is the least settled part. IETF discussion has used “dual certificates” as a category alongside composite and standalone post-quantum certificates, but that comparison lived in an individual draft that has since expired, so treat “dual signatures” as a widely understood working name rather than a term with a single canonical definition. When precision matters, the safest anchors are the published RFCs and the exact mechanism you mean: RFC 9763 related certificates, or ITU-T X.509 alternative-signature extensions.

Source: F. Driscoll, M. Parsons, B. Hale, RFC 9794, June 2025; A. Becker, R. Guthrie, M. Jenkins, RFC 9763, June 2025.

When would I use dual signatures?

You reach for dual signatures when backward compatibility with verifiers you don’t control is the binding constraint, and for a composite certificate when a clean single-object format and a format-enforced “both must hold” property matter more. The decision usually comes down to who is on the other end of the signature.

1. Choose dual when legacy verifiers must keep working untouched. 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 lets every one of them validate the classical signature today while post-quantum-aware verifiers get the extra protection. This is the case RFC 9763 was written for.
2. Choose dual when each algorithm must stay independently usable. Because the two signatures are separable, the same certificates can be used in classical-only, post-quantum-only, or combined authentication, which suits an estate migrating unevenly.
3. Lean toward composite when you control the verifiers and want the format to enforce both. A closed environment where you can deploy composite-aware libraries gets a single certificate slot and a built-in “secure if either algorithm holds” guarantee without relying on every verifier’s policy to require both.
4. Remember the size cost either way. A dual approach carries a full post-quantum public key and signature in addition to the classical ones, and post-quantum values are large, so a TLS handshake or certificate chain inflates just as it does with composite. That weight lands on parsers, trust stores, and transport limits regardless of which pattern you pick.

Like every bridge in migration architecture, dual signatures are transitional by design. The classical half is exactly what a quantum computer forges, so it earns its place only during the window when verifiers are split, and it needs a retirement plan so it comes out before the deadline rather than lingering as permanent overhead behind a reassuring word. Designing so that swap is a configuration change rather than a rebuild is crypto-agility.

Common misconceptions

1. “A dual signature and a composite certificate are the same thing.” They are opposite designs. A composite certificate fuses both algorithms into one signature object that validates only as a unit; a dual signature keeps two separable signatures, each legible on its own. RFC 9794 names them the non-composite and composite branches of hybrid signing.
2. “Two signatures automatically means an attacker has to break both.” Only if the verifier requires both. With separable signatures the “require both” decision lives in verifier policy, not in the format, and the ITU-T alternative-signature form even specifies using one key at a time, so combined strength is a policy choice rather than an automatic property.
3. “Dual signatures protect my data from being decrypted later.” Signatures protect authenticity and integrity, so dual signatures defend against forgery, not against harvest-now-decrypt-later decryption. Confidentiality is a job for hybrid key exchange, a separate mechanism on a separate timeline.
4. “There’s a finished IETF standard called dual signatures.” There is no single unified RFC by that name. The pieces are standardized separately, RFC 9794 for terminology, RFC 9763 for related certificates, ITU-T X.509 for alternative-signature extensions, and “dual” is a working name rather than one canonical term.
5. “Carrying a post-quantum signature in extensions makes my whole chain quantum-safe.” The protection is only as strong as the weakest certificate in the chain. A dual end-entity certificate that chains up through a classical-only intermediate or root still hangs from a quantum-forgeable trust anchor.
6. “Dual signatures are the permanent post-quantum answer.” They are a compatibility bridge sized for the transition. The classical component is quantum-vulnerable by definition, so a dual deployment with no plan to move to post-quantum-only signing is carrying dead weight and masking an unfinished migration.

Questions people ask

What exactly is signed in a dual signature? The same data is signed twice, independently. In the two-certificate form each certificate’s key signs the message on its own; in the alternative-signature form the certificate’s contents are signed once by the primary classical key and again by the post-quantum key, with the second signature computed over everything except the primary signature and the alternative-signature field itself.

How does a verifier check a dual signature? It depends on the verifier. A legacy verifier checks only the classical signature it understands and ignores the post-quantum one, which is what makes the approach backward compatible. A post-quantum-aware verifier can check both, and a strict policy can require both to pass before trusting the data.

Is a dual signature backward compatible in a way composite isn’t? Yes, that is its main reason to exist. Each signature stays in its ordinary single-algorithm format, so old software validates the classical one without any change, whereas a composite certificate presents an unfamiliar combined identifier that an un-upgraded verifier can’t validate at all.

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, because the two are separable and the enforcement decision sits with the verifier. If a verifier accepts either signature alone, the security reduces to whichever algorithm it checked.

Which one should I deploy, dual or composite? Favor dual when the verifiers on the other end are ones you can’t upgrade on your own timeline, and composite when you own the verifiers and want a single certificate slot with a built-in both-must-hold property. Many large migrations use each where it fits, alongside cross-certification at the trust-hierarchy layer.

Is there a real standard behind dual signatures? Pieces of it, yes. RFC 9763 (related certificates) and RFC 9794 (hybrid terminology) are published RFCs, and ITU-T X.509 (2019) specifies the alternative-signature extensions. What doesn’t exist is a single unified IETF “dual signatures” RFC, so cite the specific mechanism rather than a blanket standard.

When does the classical signature come out? When post-quantum-only signing is practical across the verifiers that matter to you and the migration is genuinely complete. The classical half is quantum-forgeable by definition, so once a cryptographically relevant quantum computer is a near-term concern and verifiers validate post-quantum signatures directly, the classical signature has done its bridging job and should retire.

---

Everything here is the map, given freely. When your team needs its own certificates and signing services assessed for a dual or composite rollout that actually delivers the guarantee and plans its retirement, that’s the work I do. Request an alignment briefing.

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