Post-quantum root CA rollover for air-gapped OT sites

A post-quantum root CA rollover on air-gapped systems replaces an RSA or ECDSA trust anchor with one based on ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). It is done on devices that cannot reach a repository or an OCSP responder. The new root, the link certificates and the revocation data all have to travel by physical media, so the process needs careful planning.

Operators of substations, water treatment plants and production lines usually have no live path to a PKI. That makes the steps that are routine on internet-connected systems much harder: announcing a new root key, fetching CRLs and checking freshness. This article covers the mechanics, the sizes involved and a workable update rhythm.

How do you replace an RSA root CA with a post-quantum root CA on devices that are offline?

Use the root CA key update procedure from RFC 4210 (CMP). You issue link certificates so that the old and new roots vouch for each other, then deliver the new root out of band with a fingerprint you have verified. On offline devices, firmware support for the new algorithm has to come first.

RFC 4210 states the core idea in one sentence: “The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa.” To do this, the CA operator must generate a new key pair; create a certificate containing the old CA public key signed with the new private key (the “old with new” certificate); create a certificate containing the new CA public key signed with the old private key (the “new with old” certificate); and create a certificate containing the new CA public key signed with the new private key (the “new with new” certificate).

The RFC is clear about who carries the burden. When a CA changes its key pair, those entities who have acquired the old CA public key via “out-of-band” means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. In an air-gapped OT zone, that description covers every device.

A sequence that works without connectivity

1. Inventory algorithm support. List every relying party: PLC gateways, HMI servers, historians, encryption gateways. Record whether its firmware can parse ML-DSA or SLH-DSA object identifiers. The IETF LAMPS work specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists.
2. Update firmware before trust. A NewWithOld certificate is signed with RSA, so a legacy device can check that it is authentic. That device still cannot validate a chain signed with ML-DSA. Link certificates connect the old and new trust anchors. They do not give a device the ability to verify a new algorithm.
3. Hold the root ceremony offline and record a fingerprint. RFC 4210 says end entities that acquire this fingerprint securely via some “out-of-band” means can then verify the CA’s self-certificate.
4. Ship a signed bundle on controlled removable media. It should contain NewWithNew, NewWithOld, OldWithNew, the first CRL from the new root and the new intermediate certificates.
5. Reissue end-entity certificates under the new hierarchy. Remove the old root only after its last certificate has expired.

The authors of an IETF draft on post-quantum root rekeying point out a weakness in the classic procedure: “these approaches rely on the assumption that the old entities can be updated.” If some OT devices can never receive new firmware, they stay on the RSA hierarchy until they are replaced. Isolate them in their own network segment and set a retirement date for them.

Can old and new trust anchors run side by side during a post-quantum PKI migration?

Yes. RFC 4210 explicitly supports a period of overlap, and most migrations need one. The old public key stays valid until every relying party holds the new one and every certificate issued under the old key has expired.

RFC 4210 notes that the old CA private key is then no longer required. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired the new CA public key. It also sets a hard limit on that overlap: the validity periods of certificates issued with the old CA key pair cannot exceed the end of the OldWithNew validity period.

The overlap has an end date. In NIST IR 8547, NIST states it will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. For US federal high-impact systems the deadline is earlier: these systems must adopt post-quantum cryptography for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. Root certificates for OT often run 10 to 20 years, so an RSA root issued today would outlive both deadlines.

Key agreement and trust anchors are separate tracks. A gateway such as Quantum Network’s QPN combines a classical exchange and an ML-KEM (FIPS 203) exchange into one session key, which protects data in transit against later decryption. Rolling over the signatures in any PKI used to authenticate infrastructure is a separate project with its own timeline.

How big do CRLs get when they are signed with ML-DSA?

An ML-DSA signature adds a fixed amount to each CRL file, roughly 2.4 to 4.6 KB depending on the parameter set. It does not add anything per revoked entry. The number of revoked certificates still decides how large a CRL ends up.

Under RFC 5280 a CRL is a CertificateList made of a tbsCertList plus one signatureValue. The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate/tbsCertList. The signature therefore appears once per file, however many serial numbers the CRL lists.

FIPS 204 lists ML-DSA-65 at 4032 | 1952 | 3309 bytes for private key, public key and signature. Across the three parameter sets, signatures are 2 420, 3 309, and 4 627 bytes for ML-DSA-44/65/87 respectively. On the hash-based side, NIST’s Quynh Dang lists the smallest option, SLH-DSA-SHA2-128s, with a signature is 7,856 bytes. The IETF SLH-DSA certificate draft lists id-(hash-)slh-dsa-sha2-256f | 5 | 49856 bytes at the top security level.

In practice, a small OT CA with a few revocations will publish CRLs that are mostly signature. A large enterprise CA’s CRL will barely change in size. The bigger effect is on the chain: each intermediate certificate signed by a root carries the root’s signature plus its own public key. If you choose SLH-DSA for a root that signs rarely, every handshake that sends the intermediate certificate also carries that large signature. On constrained serial-to-IP links, that weighs more than CRL size does.

How do air-gapped OT sites check certificate revocation without OCSP?

They use full CRLs, and optionally delta CRLs, delivered by controlled media to a CRL distribution point inside the site. Each relying party applies an explicit rule for what happens when the CRL becomes stale.

The X.509 profile in RFC 5280 (carried over from RFC 3280) makes CRLs self-contained. When CRLs are issued, the CRLs MUST be version 2 CRLs, include the date by which the next CRL will be issued in the nextUpdate field (section 5.1.2.5), include the CRL number extension (section 5.2.3), and include the authority key identifier extension. The CRL number lets an offline device reject an older CRL that someone has replayed from old media.

Delta CRLs can cut transfer size, but only where every device supports them, because conforming applications are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA.

Decide on stale CRLs before they occur

Relying parties are allowed to set their own policy. Even if the current time is after the time specified in the nextUpdate field of a CRL, an application may still make a local decision to treat the CRL as being sufficiently up-to-date. In OT, failing hard on a stale CRL can stop authenticated control traffic, while failing soft can let a revoked certificate keep working. Write the rule down for each asset class. Also check device clocks: a device without a trusted time source can misjudge both thisUpdate and nextUpdate.

How often should offline encryption gateways get CRL and trust store updates?

CRLs should arrive well within each CRL’s nextUpdate window, typically at half the window or less. Trust store updates follow the root rollover calendar rather than a fixed interval.

A useful reference is NIST’s reference certificate policy template. It proposes that offline CAs that issue CRLs must issue CRLs at least once every days, and the nextUpdate time in the CRL may be no later than days after issuance. The values in angle brackets are placeholders for each organisation to set, but they reflect a realistic cadence for an offline CA.

Each delivery should be one signed package, verified at the site boundary before any relying party imports it. It should contain the current CRLs, the CRL numbers and the trust anchor set. The RFC 4210 revision defines a data structure MAY be used to announce this event when a CA updates its key. Even if you never run CMP online, you can reuse that structure, with the three certificates, as the format for the offline package.