Root rollover and cross-signing

Mental model

In the previous lessons you saw how a certificate chain grows with PQC and how that growth affects OCSP, CRL and MTC. This lesson focuses on the most critical part at the top of the chain, the root: why changing a root (a rollover) is not a simple “generate a new key” operation, and how cross-signing bridges that transition.

What triggers a root rollover

A root rollover has three real triggers: key compromise (the most urgent scenario), algorithm sunset (for example RSA reaching end of life under the quantum threat, the subject of this course), and expiry (the ISRG Root X1 example below was generated in 2015 to expire in 2035, with a validity of 20^SOURCED; that is a typical order of magnitude for roots, but each CA chooses its own). The PQC transition falls into the second category: the root itself is not compromised, but the math it rests on (RSA/ECC) will be compromised in the future, so a proactive transition is planned.

Why it takes years: distribution, not cryptography

The real bottleneck of a root rollover is not generating the new key (that takes minutes) but getting the new root into every client’s trust store (root store; browsers, operating systems, enterprise systems). That depends on those clients being updated, and some devices (old phones, embedded systems that are never updated) never update. In the real world, years can pass between publishing a new root and that root being universally trusted.

Cross-signing: a bridge during the transition

Cross-signing is the technique that makes this transition manageable: an old, already trusted root signs the new root (or an intermediate under the new root). A client that does not yet recognize the new root can then validate the chain through the old root; a client that recognizes the new root validates directly through it. Both work at the same time, and each client uses whichever it recognizes.

A real, well-documented example: Let’s Encrypt’s own root, ISRG Root X1, was cross-signed by IdenTrust’s DST Root CA X3; this let Let’s Encrypt certificates work even while ISRG Root X1 was not yet in every device’s trust store. The cross-sign ended on 30 September 2021; after that date, old devices that did not recognize ISRG Root X1 in their own trust store (Let’s Encrypt’s own examples: an iPhone 4, an HTC Dream, devices that never received software updates) started getting certificate warnings. The case shows two things: cross-signing really works (the transition ran smoothly for years), but it is not infinite (the cross-sign itself has an end date, and that date must be planned).

Diagram: root rollover + cross-signing

ROLLOVER TRIGGER: algorithm sunset (RSA/ECC reaching end of life under the
quantum threat); NOT key compromise or expiry, which are urgent/reactive
triggers; the scenario here is proactive and planned.

BEFORE THE TRANSITION (today):
  [RSA/ECC Root] --signs--> [RSA/ECC Intermediate] --signs--> [RSA/ECC Leaf]
  All clients trust the RSA/ECC Root.

DURING THE TRANSITION (with a cross-sign):
  [RSA/ECC Root] --signs--> [RSA/ECC Intermediate] --signs--> [RSA/ECC Leaf]
        |
        +--cross-sign--> [ML-DSA Root] --signs--> [ML-DSA Intermediate] --signs--> [ML-DSA Leaf]

  Two paths to the same ML-DSA Intermediate:
  - Old client: RSA/ECC Root -> (cross-sign) -> ML-DSA Intermediate -> ML-DSA Leaf
  - New client: ML-DSA Root (recognized directly) -> ML-DSA Intermediate -> ML-DSA Leaf

AFTER THE TRANSITION (when the cross-sign expires):
  [ML-DSA Root] --signs--> [ML-DSA Intermediate] --signs--> [ML-DSA Leaf]
  Only clients that recognize the ML-DSA Root keep working;
  non-updated clients still dependent on the RSA/ECC Root get errors
  (like the iPhone 4 / HTC Dream example in the Let's Encrypt case).

The “checkable” part of this diagram is that it states explicitly, at each stage, which client trusts which root; an architect looking at it can ask directly “when does the cross-sign end, and which clients will still depend on the old root on that date?” The rollover runbook in your Project 2 should be this diagram adapted to your own bank’s real client inventory (which systems use which root store).

Numbers to know

Let's Encrypt's ISRG Root X1 could be trusted, thanks to a cross-sign from DST Root CA X3 (IdenTrust), even while its own root was not yet in every device's trust store; the cross-sign ended on 30 September 2021, and from then on old devices that did not recognize ISRG Root X1 (e.g. devices that never got updates, such as the iPhone 4 or HTC Dream) started getting certificate warnings

Lab: Draw your own root rollover diagram

[not run] This is a design exercise, not a runnable command

shell

# Redraw the ASCII diagram below for your own bank's scenario: show which intermediate steps (cross-sign, dual-root period) the move from the current RSA/ECC root to a new ML-DSA root will go through

Recorded output

A diagram: the old root, the new root, the cross-sign arrow between them, and a timeline showing which clients trust which root at which stage

At the table

How to say this in a bank meeting.

To an executive

Moving our root key to ML-DSA is not an overnight operation; it can take years for clients that trust the old root (some old devices, enterprise systems) to learn the new one. That is why our transition plan starts with cross-signing, not a hard cutover.

To an architect

The real bottleneck of a root rollover is not cryptography but distribution: the new root getting into every client's trust store depends on device updates, and some devices never update. Cross-signing bridges this transition by keeping the old and new roots trusted at the same time; but the cross-sign itself has an expiry date, which must also be planned.

Objection

“"We have published our new ML-DSA root, so the transition is done, isn't it?"”

Answer

No; publishing is only the beginning. Let's Encrypt's own ISRG Root X1 transition is a real example: the new root was created in 2015, but without the old root's (DST Root CA X3) cross-sign, millions of old devices that were not updated would have got certificate errors; the cross-sign itself lasted until 2021, and even then some devices were still affected (for example old phones that never got updates). Our ML-DSA root needs the same discipline: publishing the new root is the start of the transition, not the end.

Project linkThe basis of the rollover runbook in Project 2 (PQC PKI); the diagram below is the starting template for Project 2's own root transition design.