up:: Migration Architecture MOC

Cross-Certification

Cross-certification is a PKI technique in which one Certificate Authority issues a certificate for another CA’s public key, creating a trust bridge between two separate PKI hierarchies. The vouching certificate is called a cross-certificate, and RFC 5280 defines it precisely: cross-certificates are CA certificates in which the issuer and subject are different entities. A relying party that already trusts the first CA can then validate certificates issued under the second CA by tracing the chain across the bridge, without adding the second CA’s root to its trust store first. That property makes cross-certification a workhorse of the post-quantum transition, because an existing classical root that’s already widely trusted can vouch for a new post-quantum root so its certificates validate right away while trust stores catch up on their own slower schedule.

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, §3.2, May 2008.

The short version:

• Cross-certification is one CA issuing a certificate that vouches for a different CA’s public key, so trust flows from one PKI hierarchy into another across the bridge.
• It works at the CA-hierarchy level, so it bridges whole trust domains rather than combining algorithms inside a single certificate.
• Its post-quantum job is to let a trusted classical root vouch for a new post-quantum root, so post-quantum certificates validate through an anchor relying parties already trust while their trust stores catch up.
• A bridge CA is a specialized use of it, a hub that cross-certifies with one CA in each participating PKI so the number of trust relationships grows linearly instead of exponentially. The U.S. Federal Bridge CA is the canonical example.
• It differs from composite certificates, which fuse two algorithms inside one certificate, and from dual signatures, which run two parallel chains. The three solve different problems and are often deployed together.
• The bridge itself is signed with the classical CA’s classical key, so it’s a transitional measure that a CRQC can eventually forge. It retires once the new root is natively trusted.

Picture two countries with separate passport systems. Every border booth in Country A already recognizes Country A passports. A new agency, Country B, starts issuing a passport style no border booth recognizes yet, and reprogramming every booth in the world would take years, with some remote booths never getting the update. So instead, Country A’s passport office signs an official letter that says “we vouch for Country B’s issuing office as legitimate.” Now a traveler carrying a Country B passport presents that letter alongside it, and any booth that already trusts Country A honors the whole package, because the trust it already holds reaches across the letter to the new passport. The letter is the cross-certificate, and the booths never had to be retrained.

What is cross-certification?

Cross-certification is a trust-extension mechanism that lives at the PKI hierarchy level rather than inside any single certificate. The two authoritative definitions agree on the essentials. RFC 5280 defines a cross-certificate structurally as a CA certificate in which the issuer and subject are different entities, and describes the cross-certification exchange this way: two CAs exchange the information used in establishing a cross-certificate, and a cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates. RFC 4158, the certification-path-building profile, gives the purpose-driven version: a cross-certificate is a certificate issued by one CA to another CA for the purpose of establishing a trust relationship between the two CAs.

Source: RFC 5280, §3.2 and §3.5, May 2008; R. Housley, P. Hesse, M. Cooper et al., “Internet X.509 Public Key Infrastructure: Certification Path Building,” IETF, RFC 4158, §1.3, September 2005.

The key thing to hold onto is the layer it operates at. A Certificate Authority normally sits at the root of its own trust hierarchy, and every certificate under it chains up to that root. A relying party trusts a hierarchy by holding its root certificate in a trust store. Cross-certification builds a signed link from one hierarchy’s CA to another hierarchy’s CA, so trust that already terminates at the first root can now reach certificates that belong to the second hierarchy. Nothing about the individual end-entity certificates changes. What changes is that a new, verifiable path exists from an anchor a relying party already trusts to a certificate it previously had no way to validate.

Why does cross-certification matter for a post-quantum migration?

Cross-certification matters because a post-quantum migration eventually needs new post-quantum root CAs, and getting a new root trusted is one of the slowest, least controllable steps in all of PKI. Trust in a root comes from that root’s certificate physically sitting in a relying party’s trust store, and those trust stores live inside operating systems, browsers, mobile devices, embedded firmware, and appliances that update on their own schedules. Rolling a brand-new root out to all of them is measured in months and years, and for embedded or air-gapped systems it can be impractical to coordinate at all. If a certificate authority stood up a post-quantum-only root today, nothing that root signed could be validated anywhere until that universal trust-store rollout finished. No CA can move first under those conditions.

Cross-certification breaks the deadlock. An existing classical root that’s already present in nearly every trust store issues a cross-certificate vouching for the new post-quantum root. From that moment, a relying party that trusts the classical root can validate post-quantum-signed certificates by tracing the chain across the bridge, even though it has never heard of the post-quantum root directly.

The certificate authority gets to deploy post-quantum certificates now, and the population of relying parties that trust the post-quantum root natively grows underneath the bridge over time. Once native trust is widespread enough, the bridge stops being load-bearing and can be retired.

There’s an algorithm boundary worth naming, because it defines exactly what this buys you and what it doesn’t. The cross-certificate is signed by the classical CA using its classical key, since that’s the key relying parties already trust. Everything below the post-quantum root, its intermediates and end-entity certificates, uses post-quantum algorithms like ML-DSA. So the trust path transitions from classical to post-quantum at the cross-certificate itself.

This is why cross-certification is a transitional bridge rather than a destination. Certificate signatures anchor identity and integrity, so the relevant threat is PKI Collapse: once a cryptographically relevant quantum computer can run Shor’s algorithm against the classical CA’s key, it can forge that classical signature and therefore forge the cross-certificate, collapsing the bridge. The bridge is safe only for as long as the classical anchor it depends on is safe.

How does cross-certification actually work?

Cross-certification works by having a trusted CA sign a certificate whose subject is a second CA’s public key, then letting relying parties trace a validation path across that signed link. Walking it through end to end:

1. Issuance. The trusted classical authority, call it CA-A, issues a certificate whose subject field names the new post-quantum authority CA-B and whose subject public key is CA-B’s key. CA-A signs that certificate with its own private key. The certificate asserts, in effect, “I, the already-trusted CA, vouch for this other CA’s key for the purpose of issuing certificates.”
2. Validation path. A relying party that trusts CA-A but has never added CA-B to its trust store validates a CA-B-signed certificate by building the chain: trusted anchor CA-A, then the cross-certificate where CA-A vouches for CA-B, then any CA-B intermediates, then the end-entity certificate. The chain terminates at an anchor already in the trust store, so it validates.
3. Direction and cross-certificate pairs. Cross-certification can be one-way, where CA-A vouches for CA-B but not the reverse, or mutual, where each authority certifies the other. A mutual relationship produces two certificates that directory schemas store together as a cross-certificate pair. RFC 4523’s crossCertificatePair attribute holds exactly this, with a forward element for the certificate issued to a given CA (issuedToThisCA) and a reverse element for the certificate that CA issued to others (issuedByThisCA), so a path builder can traverse the bridge in either direction.
4. Algorithm boundary. Because CA-A’s signing key is classical, the cross-certificate is a classical signature. Every certificate below CA-B is post-quantum. The path therefore crosses from classical to post-quantum precisely at the cross-certificate, which is the layer that inherits the classical algorithm’s eventual quantum vulnerability.

Source: RFC 4523, §4.3, “Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates,” June 2006 (the crossCertificatePair attribute and its forward/reverse elements); RFC 5280, §6, certification path validation.

What is a bridge CA, and how does it scale cross-certification?

A bridge CA is a certificate authority whose whole job is to be a shared hub for cross-certification, so that many separate PKIs can trust each other without every pair of them having to set up its own direct cross-certificate. RFC 4158 defines it directly: a bridge certification authority is a nexus to establish trust paths among multiple PKIs, the bridge cross-certifies with one CA in each participating PKI, and each participating PKI cross-certifies only once with the bridge.

That single design choice is what makes bridges scale. In a full mesh where every PKI cross-certifies every other PKI directly, the number of trust relationships grows exponentially with the number of participants. Route everything through a bridge instead and the number of relationships grows linearly, one per participating PKI.

Source: RFC 4158, §1.5.4 (bridge structures and the linear-versus-exponential scaling of cross-certified relationships), September 2005.

The U.S. Federal PKI is the canonical working example, and it’s run exactly this way. The Federal Bridge Certification Authority (FBCA) cross-certifies affiliate and partner CAs, and all cross-certified CA certificate policies are mapped to the Federal Bridge certificate policy, which is how a certificate issued deep inside one agency’s PKI can be trusted by a relying party anchored in another. A parallel Federal Common Policy CA anchors the government’s hierarchical trust. Because this cross-certification machinery is already operational and well understood, adding a post-quantum root to a bridge follows the same established pattern rather than inventing a new one. The bridge cross-certifies the post-quantum root, and every PKI already connected to the bridge can reach post-quantum certificates through it.

Source: U.S. General Services Administration, Federal CIO Council, “Federal PKI Governance and Compliance,” idmanagement.gov/fpki (FCPCA, FBCA, and cross-certified policy mapping).

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

The difference is the layer each one operates at, and mixing them up is the single most common confusion in migration planning. All three let a PKI carry more than one algorithm through the transition, and they solve genuinely different problems, which is why a large migration often uses several of them together.

Composite certificates combine two algorithms inside one certificate, fusing a classical and a post-quantum key and signature under one algorithm identifier so the certificate validates only when both hold. That’s a format-level change to an individual certificate. Dual signatures, sometimes called the parallel approach, keep two fully independent certificates or signature chains side by side, one per algorithm, so each stays legible to software that only understands one of them. Cross-certification touches neither the certificate format nor the number of parallel chains. It builds a trust link between two separate certificate authorities, so it’s a topology tool for stitching hierarchies together.

Approach	What it links or combines	Layer it operates at	What it solves in the migration
Cross-certification	Two separate certificate authorities, joined by a signed vouching certificate	PKI hierarchy / trust topology	Gets a new post-quantum root trusted before relying parties update their trust stores
Composite certificate	Two algorithms fused inside one certificate under one identifier	Certificate format	Carries classical and post-quantum protection in a single certificate that keeps the protocol unchanged
Dual signatures	Two parallel certificates or signatures, one per algorithm	Certificate / chain topology	Keeps each algorithm independently legible to old and new verifiers
Hybrid key exchange	Two KEMs combined for one session key	Key-establishment step in the handshake	Protects session confidentiality against harvest-now-decrypt-later, a different guarantee entirely

The practical takeaway is that these compose rather than compete. A migration can put a post-quantum root behind a bridge using cross-certification, issue composite certificates under that root so individual certificates carry both algorithms, and separately turn on hybrid key exchange in TLS to protect confidentiality. Each move addresses a different layer of the same transition, and none of them substitutes for the others.

What are the tradeoffs of cross-certification?

The costs cluster in a few predictable places, and every one of them traces back to the fact that the bridge is a classically-signed link added to the trust path.

1. The bridge is quantum-vulnerable by design. The cross-certificate carries the classical CA’s classical signature, so a CRQC that breaks that classical key can forge the cross-certificate and mint a false path to the post-quantum root. Cross-certification buys deployment time during the window before that machine exists, and it stops delivering protection at the trust-bridge layer once one does. It’s a transitional measure, so plan its retirement rather than letting it become permanent.
2. It lengthens the validation path. Every cross-certificate adds a certificate to the chain a relying party has to build and check. Some validators enforce a maximum path length or basic-constraints limit, and a chain that crosses one or more bridges can bump into those limits, so path building has to be tested against the actual validators in use.
3. It requires cooperation and policy mapping. One CA cannot unilaterally attach itself to another’s trust. The issuing CA has to agree to vouch, and in bridged government and public-CA environments that means formal certificate-policy mapping and audits, like the Federal Bridge’s policy-mapping regime, before a cross-certificate is issued at all.
4. Mixed-algorithm chains can trip validators. A chain that transitions from a classical cross-certificate to post-quantum certificates below it exercises code paths that older validators may not handle, and some reject mixed-algorithm chains outright. Support for post-quantum algorithms across the validators on the path is a gating question for whether the bridge actually works in practice.
5. Revocation couples the two hierarchies. If the classical root that anchors the bridge is compromised and revoked, the cross-certificate falls with it, and the path to the post-quantum root breaks until native trust for that root is established. The bridge inherits the operational fate of the classical anchor it hangs from.

There’s also a discovery consideration for anyone building a crypto inventory. Cross-certificates show up in chain inspection as CA certificates where the issuer and subject belong to different hierarchies, which is an identifiable pattern, but standard tooling that assumes a simple single-root hierarchy can misread or overlook them. Knowing which of your trust paths actually cross a bridge is part of knowing what cryptography you really depend on.

Common misconceptions

• “Cross-certifying a post-quantum root makes it quantum-safe.” The cross-certificate is signed with the classical CA’s classical key, so the bridge is exactly as quantum-vulnerable as that key. Cross-certification gets a post-quantum root trusted early, and full quantum safety arrives only when relying parties trust the post-quantum root natively and the classical bridge drops out of the path.
• “Cross-certification is the same thing as a composite certificate.” They operate at different layers. A composite certificate fuses two algorithms inside one certificate, while cross-certification links two separate certificate authorities. One is a certificate-format pattern, the other is a trust-topology pattern, and a migration commonly uses both.
• “A CA can cross-certify any other CA on its own.” The vouching CA has to agree to issue the cross-certificate, and in bridged public or government PKIs that involves formal certificate-policy mapping and compliance audits before the trust link exists.
• “Cross-certification replaces trust-store updates for good.” It’s a bridge that buys time while trust stores catch up. Once the new root is natively trusted widely enough, the cross-certificate becomes dead weight and should be retired so the path stops depending on a classical anchor.
• “Adding a bridge means reissuing all my end-entity certificates.” The individual end-entity certificates are untouched. Cross-certification adds one signed link at the CA level, and the existing certificates chain up through it without being reissued.
• “A cross-certificate and a cross-certificate pair are the same object.” A single cross-certificate is one CA vouching for another in one direction. A cross-certificate pair is the two-certificate object that stores a mutual relationship, with a forward element and a reverse element, so a path builder can traverse the bridge either way.

Questions people ask

What’s the difference between a cross-certificate and a bridge CA? A cross-certificate is the individual signed object where one CA vouches for another. A bridge CA is a certificate authority built specifically to be a shared hub that issues and receives many cross-certificates, one relationship per participating PKI, so a whole community of PKIs can interoperate without every pair setting up its own direct link.

Does cross-certification make my new post-quantum root quantum-resistant? It makes the post-quantum root usable early, not quantum-safe. The bridge that connects it to existing trust is a classical signature, so a cryptographically relevant quantum computer can forge that link. The post-quantum root becomes genuinely quantum-safe once relying parties trust it directly and the classical cross-certificate is out of the path.

When can I retire the cross-certificate? When the new post-quantum root is present natively in the trust stores that matter to you. At that point relying parties reach it directly, the bridge stops carrying trust, and keeping it only preserves a classically-signed link a quantum adversary could eventually attack.

Do all the certificates below the bridge have to be post-quantum? For post-quantum protection below the bridge, yes, the post-quantum root’s intermediates and end-entity certificates should use post-quantum algorithms like ML-DSA. The classical part is confined to the cross-certificate at the top of that segment, which is the boundary the trust transitions across, and which is why the whole arrangement is transitional.

Is cross-certification a public-CA thing or an enterprise thing? Both. Enterprises use it so an existing corporate root can vouch for a new internal root without a device-fleet trust-store rollout, government PKIs use it heavily through federal bridge architectures, and public CAs can use it so certificates validate before browser and OS trust programs add a new root directly.

How does cross-certification affect certificate chain length? It adds a certificate. A relying party validating across a bridge builds a longer chain, anchor to cross-certificate to intermediates to end-entity, and if it crosses more than one bridge the chain grows further. Validators with path-length limits can reject an overly long chain, so it needs testing against the real validation software in the environment.

Can I use cross-certification and composite certificates at the same time? Yes, and large migrations often do. Cross-certification gets the post-quantum root trusted at the hierarchy level, and composite certificates carry both algorithms inside the individual certificates issued beneath it. They address different layers, so they stack cleanly.

What happens to the bridge if the classical root is compromised? The bridge falls with it. If the classical anchor is revoked after a compromise, the cross-certificate that depended on it stops validating, and the path to the post-quantum root breaks until relying parties trust that root natively. The bridge inherits the security and operational fate of the classical CA it hangs from.

---

Everything here is the map, given freely. When your team needs its own CA hierarchies, bridges, and validators assessed for a post-quantum trust migration that actually delivers early trust without leaving a classical bridge in place forever, that’s what an alignment briefing is for.

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