Cryptography and the post-quantum transition

Summary. WKL TrustBridge relies on hybrid cryptography: classical algorithms for compatibility with existing relying parties, and ML-DSA (FIPS 204) as the post-quantum signature. A hybrid certificate carries both signatures; classical verifiers read it unchanged, PQ-capable verifiers check both. For connections between partners, ML-KEM (FIPS 203) is used twice: in the hybrid group of TLS 1.3 and in the key agents' independent key exchange. Crypto agility is achieved through CA generations, not by switching algorithms at runtime. The yardstick for all algorithms and parameter sets is BSI TR-02102, edition 2026-01.

• ML-KEM – Module-Lattice-Based Key-Encapsulation Mechanism (FIPS 203): a mechanism by which two parties agree on a shared secret. FIPS 203 defines ML-KEM-512, -768, and -1024; of these, the BSI recommends only ML-KEM-768 and ML-KEM-1024 (security categories 3 and 5).
• ML-DSA – Module-Lattice-Based Digital Signature Algorithm (FIPS 204). FIPS 204 defines ML-DSA-44, -65, and -87; of these, the BSI recommends only ML-DSA-65 and ML-DSA-87, each in the „hedged“ variant (signing with additional randomness rather than purely deterministically).
• SLH-DSA – a stateless hash-based signature scheme (FIPS 205); conservative assumptions, large signatures.
• Hybrid – the combination of a classical and a PQ algorithm. The security that results depends on the construction and on what the relying party verifies (see below).
• Crypto agility – the ability to change algorithms in a planned way, without breakage.

Two threats need to be kept apart:

TrustBridge addresses both. Against the first, the hybrid TLS group and the key agents' additional secret protect; see PQ key exchange for TLS. Against the second, hybrid certificates protect. Their critical path is the trust anchors: a root generated classically today and meant to last twenty years would be worthless before it expires if a quantum computer arrives, and so would every chain beneath it.

Why hybrid rather than PQ only. ML-DSA is young; its implementations have fewer years of production use behind them than RSA or ECDSA, and experience shows that implementation bugs weigh more heavily than mathematical weaknesses. Combining both algorithms protects against either one failing, but only if the relying party verifies both signatures and treats a missing one as an error. That is why the BSI recommends PQ algorithms in combination with classical ones. At the same time, a hybrid certificate remains readable for relying parties without PQ support.

The yardstick is BSI TR-02102-1, edition 2026-01. For key agreement it recommends only ML-KEM-768 and ML-KEM-1024 (Section 2.4.3, Table 2.7), and for signatures only ML-DSA-65 and ML-DSA-87 in the „hedged“ variant (Section 5.3.4.2, Table 5.7), in each case with post-quantum algorithms combined with a classical one. TrustBridge therefore offers only these parameter sets, and only in hybrid form.

ML-DSA-44 and ML-KEM-512 do not meet this recommendation. They are not permitted in profiles, certificates, requests, or relationships; a CSR with such a key is rejected.

The identifier of a PQ signature follows the standardized identifiers from RFC 9881.

graph LR
  %% LR: The certificate fields stack vertically this way; drawn top to bottom, the diagram becomes more than twice as wide.
  CA[CA with classical<br/>and ML-DSA key<br/>in the HSM]
  subgraph CERT [Certificate]
    subgraph TBS [Signed part]
      SUB[Subject, serial number, validity]
      SPK[Classical public key]
      ALTK[subjectAltPublicKeyInfo 2.5.29.72<br/>ML-DSA key]
      ALTA[altSignatureAlgorithm 2.5.29.73]
      ALTV[altSignatureValue 2.5.29.74<br/>the CA's ML-DSA signature]
      EXT[other extensions]
    end
    SIG[The CA's classical signature<br/>over the entire signed part]
  end
  CA ==>|1. ML-DSA over the signed part<br/>without altSignatureValue| ALTV
  CA ==>|2. classical over everything| SIG
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef kl fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef neu fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  class ALTK,ALTA,ALTV pq
  class SPK,SIG kl
  class SUB,EXT neu
  class CA tcb
  style CERT fill:#ffffff,stroke:#8a8886,color:#201f1e
  style TBS fill:#ffffff,stroke:#8a8886,color:#201f1e

Two levels of the statement.

By contrast, composite signatures (IETF draft) bind both signatures inseparably under a new algorithm; classical verifiers reject such certificates. TrustBridge issues hybrid certificates with an alternative signature so that existing relying parties can keep reading them, and compensates for the separability with a PQ requirement per relationship.

Limit. The alternative signature is separable. Anyone able to forge the classical signature in the future can produce a certificate without the PQ extensions that a verifier without a PQ requirement accepts. PQ protection therefore only takes effect once relying parties require it. The TLS adapter requires it as soon as the relationship policy says so. A request for a hybrid certificate must prove possession of both private keys.

Crypto agility here does not mean switching algorithms at runtime; it means having the change planned:

1. New generation instead of re-keying. A new algorithm means a new CA with a new key and a new certificate. An existing key is never re-certified.
2. Overlap. Relying parties receive the new anchor before the first issuance under the new generation.
3. Phase-out. The old generation stops issuing once its remaining lifetime falls below the longest profile lifetime, and from then on signs only CRLs.

gantt
  title Replacing a classical generation with a hybrid one (schematic)
  dateFormat YYYY-MM-DD
  axisFormat %Y
  section Classical generation
  issuing                :a1, 2027-01-01, 2028-06-30
  CRLs only              :a2, after a1, 365d
  section Hybrid generation
  anchor distributed     :b0, 2027-07-01, 180d
  issuing                :b1, 2028-01-01, 2031-12-31

Migrating an organization's existing classical anchors: inventory the relying parties and their PQ capability; distribute the hybrid anchor alongside the old one; issue new certificates only in hybrid form; agree on a PQ requirement per relationship as soon as both sides can verify; retire the old anchor once all certificates beneath it have expired.

Dependency on the HSM. Hybrid CAs require an HSM that generates and uses ML-DSA keys non-exportably. There is no software key for a CA, not even as a transition.

Heterogeneous implementations. The certificate authority sticks to a single foundation, because every additional library in the trusted computing base multiplies the review effort. The endpoint components deliberately use a different TLS implementation: the additional secret is thus independent of the certificate authority's cryptography at the implementation level as well.

Testing against standard vectors. Every release tests ML-DSA and ML-KEM against the published test vectors from FIPS 203 and FIPS 204, including malformed keys and altered context strings. A key's parameter set is read from its object identifier, never inferred from its length.

Any HSM that passes this acceptance check is permitted for TrustBridge. A software HSM is ruled out for CA keys and intended only for test and training environments.

• A specific HSM. The requirements and the acceptance check are listed above.
• Composite signatures. TrustBridge uses the separable alternative signature so that classical relying parties can keep reading certificates.
• Algorithms outside the BSI TR-02102 recommendation, not even at the request of individual partners.

• FIPS 203 – ML-KEM.
• FIPS 204 – ML-DSA.
• RFC 9881 – identifiers for ML-DSA in X.509.
• RFC 10024 – hybrid ECDHE and ML-KEM key agreement for TLS 1.3.
• BSI TR-02102 – TR-02102-1 and TR-02102-2, edition 2026-01.
• PKCS #11 Version 3.2 – mechanisms for ML-DSA and ML-KEM.