The Cryptographic System
Every security claim on this site is spendable only because there is one cryptographic system underneath it: a single certificate-authority trust chain, one set of key-bearing material per principal, and one custody model for the private halves. This page is the map of that system, the trust chain that issues identity, the material each entity carries, how cells authenticate each other, how post-quantum issuance is offered without weakening the default, and where the private keys live.
The signing, provenance, post-quantum, and custody-lifecycle mechanisms have their own pages; this page shows how they hang together.
The CA trust chain
Trust descends a short, fixed chain. The organization is the root of trust:
it is seeded first and holds the organization's certificate authority. Under it,
each node carries an intermediate CA. Leaf certificates, for cells and for
field devices, are signed by a seeded device CA intermediate held under the
organization (org.device_ca), so a leaf's authority traces, hop by hop, back to
the organization root.
Figure E6a: the certificate-authority trust chain. The organization root (verified/green) signs a per-node intermediate CA and a seeded device CA intermediate; cell and device leaves (plain boxes) are signed one hop below. A full RFC 5280 path walk validates signatures, validity intersection, revocation, and name and basic constraints at every hop on the verifying side.
Table equivalent
| Tier | Issued by | What it is | Survives |
|---|---|---|---|
| Organization root CA | (self, seeded first) | The organization's trust root; holds the CA | |
| Node intermediate CA | Organization root | One per node; the cryptographic identity peers recognize | Cell replacement |
Device CA intermediate (org.device_ca) | Organization root | A seeded subordinate that signs device and edge leaves | Offline operation |
| Cell leaf | Node intermediate CA | A cell's identity certificate | |
| Device leaf | Device CA intermediate | An edge or IoT endpoint's certificate | Disconnection |
Per-entity cryptographic material
Every principal is issued material in three formats at once (X.509, SSH, and OpenPGP) by one issuance orchestrator that runs over per-format algorithm managers. There is no principal kind that holds one format and not the others, and there is no separate machine-identity system that issues a different sort of credential.
Figure E6b: per-entity material. One orchestrator issues all three formats for every principal immediately after its directory row is created. The OpenPGP implementation consumes both RFC 4880 (v4) and RFC 9580 (v6) material and emits v4 only, an accept-before-emit asymmetry that is deliberate, not unfinished.
Table equivalent
| Format | What it establishes | Notes |
|---|---|---|
| X.509 | Transport and document identity; carries ID and clearance | Full RFC 5280 path validation on the verifying side |
| SSH | Session identity | Issue / sign / verify / revoke / rotate at parity with X.509 |
| OpenPGP | Signed and encrypted artifacts | Accepts v4 and v6; emits v4 only (accept-before-emit) |
Cell identity and mutual TLS
A cell holds its own cell identity key and authenticates to every peer cell over mutual TLS, with identity carried in the client certificate. There is no inter-cell call that is unauthenticated. A cell acts for no entity and binds no principal identity; it is infrastructure, and its leaf is signed by the node intermediate above it. This is what lets the estate be many cells without the trust between them being assumed.
Revocation on the wire: OCSP stapling
Mutual TLS proves which peer, but a certificate can be revoked before it expires. Two mechanisms cover that gap. On the dial side, a cell pre-flight checks revocation (OCSP, CRL, and SSH KRL) before it trusts a peer's certificate, so a revoked peer is rejected rather than merely detected later. On the serve side, a cell staples a cached OCSP response onto its own TLS listeners: the freshness proof for the cell's certificate is delivered inside the handshake, so a connecting peer sees that the certificate is not revoked without making its own round trip to a responder, which matters where that responder is slow, blocked, or unreachable.
The staple reaches the wire. The cached response is bound to the certificate context the cell actually serves, the same TLS context the server serves from, and the binding self-checks that it is attached to the correct context rather than a mismatched one; the system's own TLS library (OpenSSL) then delivers the staple during the handshake. A background prefetch keeps the cached response fresh.
The behaviour is fail-safe, not fail-loud: a certificate leaf that has no current staple is served unstapled rather than refusing to serve, so a missing or stale responder never takes a listener down, the connecting peer simply falls back to checking revocation itself, exactly as it does on the dial side.
The staple is served on the cell's TLS listeners, not merely produced and left unread. What is not claimed: that every leaf is always stapled (a leaf with no current staple serves unstapled by design), or that stapling replaces the dialing peer's own revocation check (it does not, it supplements it).
Post-quantum hybrid issuance: built, opt-in, fail-closed
A certificate safe today can be forged once its algorithm falls. The issuance
path can therefore mint a hybrid X.509 certificate that carries a classical
key alongside an ML-DSA-65 (FIPS 204) post-quantum signature, persisting both
private halves through the same code as a classical certificate. It is selected
by crypto policy (algorithm_family = hybrid or pq_only) and everything
about the default is conservative:
Figure E6c: hybrid issuance, fail-closed. The default is classical (green). A policy that asks for hybrid attempts the classical + ML-DSA-65 path; if the post-quantum half cannot complete, issuance refuses (amber, dashed) rather than quietly handing back a classical-only certificate.
Table equivalent
Policy algorithm_family | Outcome | On PQ failure |
|---|---|---|
| classical (default) | Classical X.509 issued | n/a |
hybrid | Classical + ML-DSA-65 certificate | Refuses: no downgrade |
pq_only | Post-quantum certificate | Refuses: no downgrade |
The default post-quantum OID arc is a reserved placeholder (PEN 99999, unregistered) and is runtime-warned. A deployment must set its own registered Private Enterprise Number arc before any hybrid certificate leaves the fabric. The classical half stays valid regardless.
The post-quantum hybrid signatures page covers the signature construction, independent pinning of the post-quantum half, and downgrade-by-omission refusal, that the same discipline applies to signing.
Key custody and the operator quorum
Private key material can be generated locally, held in hardware, and used without being exported (see key custody and lifecycle for the full backend matrix and the KEK hierarchy). What matters at the system level is what custody refuses, and what it does not:
Figure E6d: key-custody lifecycle. Material is generated in place, used without export, refreshed on an overlapping window, and revoked without a certificate rotation. High-sensitivity secrets are sealed and can be reconstructed only under an M-of-N operator quorum.
Table equivalent
| Stage | What happens | Offline behaviour |
|---|---|---|
| Generated | Keypair minted on the device/cell; private half never on the wire | Works offline |
| In use | Signs and authenticates without exporting the key | Works offline |
| Rotated | Overlapping refresh window, not an expiry cliff | Issuance works offline via the pre-provisioned subordinate CA |
| Revoked | Delegation bound to certificate fingerprint; revoke needs no cert rotation | Enforced on the device against its own state |
| Sealed → reconstructed | High-sensitivity secret reassembled under Shamir M-of-N | Secret reconstruction refuses offline: it needs the quorum |
The distinction that is easy to get wrong: routine issuance works offline. A disconnected cell is pre-provisioned with a subordinate CA and can issue and validate with no upstream reachable. What refuses offline is secret reconstruction, reassembling a high-sensitivity secret from its Shamir shares needs the operator quorum present, and that is a deliberate refusal, not a degraded path.
The M-of-N reconstruction shown here is built on real primitives, but it is
disabled by default, no in-memory reassembly runs until
security.crypto.threshold.enabled is set true. The M-of-N root-CA quorum is
a real Ed25519 approval ceremony (with M ≥ 2 enforced in-schema over a converged
multi-cell DAO) that stays behind that same flag and returns a typed 503 only
while it is off. Certificate revocation and BYOK now ship on the operator
surface, deny-closed, revoke drives the real X509Manager.revoke (CRL
re-publish plus revocation gossip), status is answered from the authoritative
revocation store, and BYOK proxies the real key-context service. See
Key custody and lifecycle for the full ceiling, including how
a revoked status survives a restart and the one ordering caveat on the air-gapped
courier lane.
Signed at origin: the signature travels
The whole system exists so that provenance is attached where an artifact is produced and checked where it is used, rather than asserted by a system of record in between. A signature travels with what it signs and is re-verified offline against a pinned key. That property, and the domain-separation and canonical-byte rules behind it, are on the signing and provenance page.
The certificate systems, the trust chain, per-entity issuance, mutual TLS, hybrid issuance, and the custody lifecycle are described by mechanism, not by grade, no component is presented here as certified. Hybrid X.509 issuance is built, opt-in, and default-classical. TPM-sealed custody and per-compartment key isolation are present in design; they are not claimed here as operating controls. FIPS 140-3 and CNSA 2.0 exist as policy profiles with fail-closed startup and runtime gates, a policy posture that is assessed, not a certification.
Related topics
- Signing and provenance, what is signed and how it is verified at use.
- Post-quantum hybrid signatures, the Ed25519 + ML-DSA-65 signing construction and its downgrade resistance.
- Key custody and lifecycle, backends, the KEK hierarchy, rotation, and revocation in full.
- The entity model, the principals this material is issued to.
- Authorization and delegation, how the sealed grant delegates authority a certificate cannot.