Dual PKI, composite and the CA/B Forum timeline

Mental model

In M6 you saw the hybrid, pure and composite architectures. This lesson makes that decision harder by adding one more dimension: the CA/B Forum timeline that progressively shortens TLS certificate validity directly multiplies the operational cost of the architecture you choose.

CA/B Forum SC-081v3: the timeline, from the official source

The SC-081v3 ballot approved by the CA/B Forum itself (11 April 2025, Certificate Issuers 25-0-5, Certificate Consumers 4-0-0, including all four major browser makers) shortens TLS certificate validity in three steps: 200 days^SOURCED (from 15 March 2026), 100 days^SOURCED (from 15 March 2027), 47 days^SOURCED (from 15 March 2029). This timeline is independent of PQC and already in force, but it interacts directly with your PQC architecture decision.

Why this timeline makes the architecture heavier

A 47-day cycle means a certificate is renewed about 365/47 ≈ 7.8 times a year. That turns automation (fully automatic renewal with protocols like ACME) from optional into mandatory; renewing thousands of certificates manually 8 times a year is not practical. This is where the architecture choice’s effect on that automation load comes in:

If dual PKI (parallel stack) is chosen, two separate certificate chains (one classical, one PQC) are managed for each certificate identity; each renewal cycle means two separate CSRs, two separate signing operations and two separate deployments. The automation infrastructure (ACME clients, certificate inventory, monitoring) must scale to handle this doubled operation volume.

If composite is chosen (draft-ietf-lamps-pq-composite-sigs, which you saw in M6 and which is not yet an RFC), one certificate object (carrying both the classical and the PQC signature) is renewed with one operation; the number of operations does not double, but the data each operation carries is larger (as in M6).

This is an additional engineering trade-off, separate from the security dimension: dual PKI multiplies the number of operations, composite enlarges the data per operation. On the 200-day cycle of 2026 the difference is manageable; on the 47-day cycle of 2029, for an inventory of thousands of certificates, it directly affects the capacity planning of the automation infrastructure. This operational cost does not replace the security risk you saw in M6 (in dual PKI the verification logic must be AND, not OR; verification designed with OR logic means an attacker who breaks the classical algorithm can bypass the PQC chain with no effort); it is an additional layer on top: if dual PKI is chosen, both the correct implementation of AND logic and the automation infrastructure’s ability to handle the multiplied volume must be verified separately.

Diagram: architecture choice x CA/B Forum timeline

                    2026 (200 days/cycle)      2029 (47 days/cycle)
                    ~1.8 renewals/year         ~7.8 renewals/year

DUAL PKI:
  [Classical Root] -> [Classical Int.] -> [Classical Leaf]  <- renewed separately
  [PQC Root]       -> [PQC Int.]       -> [PQC Leaf]        <- renewed separately
  1000 cert identities x 2 chains x 1.8/year     1000 x 2 x 7.8/year
  = ~3600 operations/year (2026)                 = ~15600 operations/year (2029)

COMPOSITE:
  [Composite Root] -> [Composite Int.] -> [Composite Leaf]  <- one renewal
  (each certificate carries both a classical and a PQC signature, one object)
  1000 cert identities x 1 chain x 1.8/year      1000 x 1 x 7.8/year
  = ~1800 operations/year (2026)                 = ~7800 operations/year (2029)

The “checkable” part of this diagram is that the calculation on the right can be redone with your own bank’s real certificate count: replace 1000 with your own inventory and you see the real operation volume your automation infrastructure must handle in 2029. The architecture decision in your Project 2 needs to answer not just “which is more secure” but also “can our automation infrastructure handle 2029’s volume”.

Lab: Compute the renewal volume for your own bank

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

shell

# Take your bank's current certificate inventory (number of leaf certificates) and compute the annual renewals under the 47-day cycle of 2029: inventory x 7.8

Recorded output

An inventory renewed once a year today will be renewed ~7.8 times a year in 2029; with dual PKI this doubles per certificate (classical + PQC separately)

At the table

How to say this in a bank meeting.

To an executive

The CA/B Forum's validity reduction (47 days in 2029) is coming regardless of our PQC architecture choice; it means automation (such as ACME) is no longer optional but mandatory. Our PQC architecture choice can multiply that automation load (dual PKI) or keep it flat (composite); this is not just a cryptography decision but an operational scale decision.

To an architect

Dual PKI (separate classical and PQC certificate chains) means two separate certificate operations per renewal cycle (two CSRs, two signings, two deployments); composite (two signatures in one certificate) means one operation but one larger object. On a 47-day cycle, dual PKI's doubled operational load means the automation infrastructure (ACME clients, certificate management systems) must run at twice the capacity.

Objection

“"Dual PKI is more flexible; we can manage classical and PQC separately. Why move to composite?"”

Answer

The flexibility is a real advantage, but it has a price: on the 200-day cycle of 2026 the price is manageable, but on the 47-day cycle of 2029, two separate renewal operations per certificate identity require doubling the capacity of our automation infrastructure. Composite (as you saw in M6, not yet an RFC) solves this scaling problem by keeping it to one operation; today's decision has to account for 2029's volume, not just today's.

Project linkThe final piece of the architecture decision in Project 2 (PQC PKI); the diagram below is Project 2's rationale template for how the dual PKI/composite choice interacts with the CA/B Forum timeline.