PKI and Chains of Trust

Andi Lamprecht ·2026-05-11· 9 min read· Draft

1. The Hierarchical Model

A typical chain has three layers: a Root CA, one or more Intermediate CAs, and a leaf (end-entity) certificate. Root CAs never sign leaf certificates directly — if a root’s private key were compromised, every certificate it ever signed would be untrustworthy and replacing the root requires updates across every consumer that holds the trust anchor. Intermediates act as a buffer: a compromised intermediate can be revoked without touching the root.

    flowchart TB
    Root["Root CA<br/>HSM-backed, offline, rarely used"]
    Int1["Intermediate CA"]
    Int2["Intermediate CA"]
    Leaf1["Leaf certificate<br/>end entity"]
    Leaf2["Leaf certificate<br/>end entity"]
    Leaf3["Leaf certificate<br/>end entity"]
    Root --> Int1 --> Leaf1
    Int1 --> Leaf2
    Root --> Int2 --> Leaf3
    classDef root fill:#fff7d6,stroke:#b58900
    classDef inter fill:#eef3ff,stroke:#1f6feb
    class Root root
    class Int1,Int2 inter
  

2. How Verification Works

When a TLS connection is established, the server sends the leaf certificate and the intermediate chain — but not the root. The verifier reads each certificate’s Issuer field to find the parent, then verifies the parent’s signature using the parent’s public key. This continues until the chain terminates at a Root CA already present in the local trust store.

If the server omits intermediates, the verifier can fall back to the Authority Information Access (AIA) extension embedded in the leaf certificate, which contains a URL pointing to the missing parent.

3. Signature Verification

Each certificate contains a signature produced by the issuer’s private key over a hash of the certificate’s data. The verifier validates the signature using the issuer’s public key against its own hash of the certificate data. A match proves the issuer signed it.

The “decrypt with public key” mental model is RSA-specific. ECDSA and Ed25519 do not encrypt anything during verification — they verify the signature mathematically against the hash and the public key. ATOMx is algorithm-neutral at the protocol layer.

This is the same mechanism whether the issuer is a public web CA, a federal CA, the ATOMx Root CA, or a TPM chip manufacturer’s CA. The trust comes from where the verifier obtained the root public key, not from any property of the signature itself.

3.1 Signature Algorithms in ATOMx

ATOMx never uses MD5 or SHA-1 in any cryptographic role. Algorithm identifiers are carried explicitly in every signed object (e.g., signature_algorithm in the Authorization Package Manifest) so verifier code does not depend on out-of-band agreement.

3.2 Certificate Format and Validity

4. Trust Store

Root CA certificates are distributed out of band — via OS updates, browser updates, firmware images at manufacture, or sealed configuration files. This is the foundational anchor. It cannot be bootstrapped over the network; if it could, an attacker on the network could install themselves as the root.

In ATOMx:

AIA fallback is supported but not relied upon: aircraft and authority field devices in disconnected mode cannot fetch over the network, so all required intermediates are pre-distributed.

5. Root CA Operational Model

The ATOMx Root CA is held in a Hardware Security Module (HSM) — a tamper-resistant device that holds the private key and performs signing operations without ever exposing the key to the host. The Root HSM is kept offline. It is brought online only for infrequent, audited key ceremonies under dual control to sign new intermediate CAs.

Intermediate CAs are themselves HSM-backed but online, and sign end-entity certificates routinely.

For the specific intermediates ATOMx operates (Manufacturer, Operator, Pilot, Authority), see Disconnected Operations §2.2. For the OEM-side ceremony that issues Manufacturer intermediates, see Onboarding Manufacturers §3.

5.1 FIPS Posture and HSM Custody

6. Revocation

6. Revocation

Four approaches are in play across ATOMx:

Disconnected verifiers carry a signed CRL snapshot inside each Offline Capsule and refuse capsules referencing revoked credentials. See Disconnected Operations §3.1 and Threat Model §5–§6 for revocation-related threats.

7. Cross-References

• Pilot credentials and identity-proofing chains: Pilot Identity
• Aircraft TPM / EK / Assembly Certificate dual-chain model: Aircraft Hardware Identity
• The ATOMx-internal trust hierarchy and intermediate CAs: Disconnected Operations §2

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.