ML-DSA certificates through EST
Certificates with ML-DSA-44, 65 or 87 subject keys (FIPS 204, encoded per RFC 9881), issued through standard EST from a request made by a stock OpenSSL 3.5 client. The issued certificate verifies. The test →
Crypto agility · post-quantum alpha
One crypto boundary. Post-quantum is the first proof.
Every cryptographic operation in trstctl enters through a single package and runs on a backend registered behind it. A build-time linter fails the build on a crypto import anywhere else. Adding or swapping an algorithm is one contained change, and the post-quantum migration is the first one run end to end.
This page lists what ships today, the test that proves it, and what trstctl does not claim yet. The second list is the point.
What runs today
Six things you can check.
Each one is in the repository with a test behind it, and ships in every edition. Nothing here needs a license.
The host agent keeps the choice
Enroll a host with an ML-DSA key and the agent generates it on the host. Renewals keep that algorithm; nothing silently falls back.
Keys stay in the isolated signer
The signer generates, seals and reloads ML-DSA, SLH-DSA and ML-KEM keys in locked, zeroed memory, across restarts. The control plane never holds them.
The inventory knows what is vulnerable
Every scanned key is rated, the quantum-vulnerable ones are flagged, and each is mapped to its FIPS 203, 204 or 205 replacement. Campaigns carry owners, deadlines, dependency-ordered readiness and signed closure you can verify offline. Find it before you renew it →
Every edition, no license
Post-quantum support and proof-carrying succession attach in every build, including the free core. There is nothing to unlock.
Proof-carrying succession patent pending preview
Each move to a new signing algorithm is a record that both the old key and the new key sign over one commitment, with an epoch counter against replay and a break-glass requirement for any move to a weaker class. Records go to a transparency log with signed checkpoints and verify offline. API only today.
What we do not claim
Read this list before the one above.
Anyone can add an algorithm once. The claim worth checking is that every future migration is a contained change, and that is only believable if the limits are written down. These are, here and in the limitations page.
- Quantum-safe TLS. trstctl’s own listeners negotiate classical key exchange today (X25519, P-256, P-384). Hybrid post-quantum key exchange is not offered yet.
- Post-quantum CA chains. The issuing CA is classical ECDSA P-256. Post-quantum keys are subject keys under a classical issuer, which is the posture stock TLS clients can chain to.
- Composite certificates. The hybrid certificate is ECDSA P-256 plus a trstctl-private extension carrying an ML-DSA key. It is not an IETF composite certificate, and no shipped client builds that request yet.
- SLH-DSA certificates. SLH-DSA keys live in the signer. Nothing issues certificates on them.
- Post-quantum keys in HSMs. The PKCS#11 and cloud KMS backends handle RSA and ECDSA keys only.
- FIPS-validated post-quantum. The post-quantum package is not part of Go’s validated module, and the FIPS build mode does not make it so.
- One-click estate re-keying. What ships is the inventory, the campaign, and re-issuance through the normal enrollment paths. An orchestrated re-key with rollback is not released.
- Succession driving re-issuance. Proof-carrying succession records moves. It does not yet re-issue certificates, and it has no console page.
- Pure ML-DSA over SCEP. SCEP’s reply format needs a key-transport key that a signature-only algorithm does not have, so SCEP cannot carry it by protocol. EST and the Workload API can.
Why one boundary
The architecture is the asset. Post-quantum is its first demo.
Migration is a module, not a program
The transitions of the next decade, ML-DSA, ML-KEM and SLH-DSA today, whatever follows a lattice break, a mandated national algorithm for a sovereign customer, each register behind the boundary. The enrollment protocols, the policy engine, the inventory and the console do not change.
A crypto CVE has a blast radius of one package
When a primitive breaks, the surface to audit and replace is one tree, not every call site that ever needed a signature. The linter is what keeps a second crypto path from growing.
Keys are structurally out of reach
Signing lives in a separate process with no HTTP server and no database driver, reached over a Unix socket or mTLS. The control plane can request a signature. It cannot produce one.
trstctl.com/crypto-agility
Read the limits first. Then run it.
Inventory the cryptography you have, enroll one host with an ML-DSA key, and verify the certificate with the OpenSSL you already run.