Day 29: CA Hierarchy Design

Phase 1 · June 11, 2026

Agenda (2–3 hours)

• Read (75 min): CA/Browser Forum Baseline Requirements §6 (CA security requirements — skim); NIST SP 800-57 Part 3 §3 (PKI design — relevant sections)
• Study (45 min): Tier design, key protection requirements, operational constraints
• Challenge (60 min): Design a PKI hierarchy for a satellite provisioning system

CA Hierarchy Tiers

Root CA (Tier 1)

• Self-signed cert; in every trust store that trusts this PKI
• Private key in HSM, air-gapped machine — never connected to a network
• Used only to sign intermediate CA certs and CRLs
• Key ceremony required for any operation

Issuing Intermediate CA (Tier 2/3)

• Signed by Root (or by another intermediate)
• Private key in HSM, online (reachable by issuance services)
• pathLenConstraint limits further sub-CA creation
• nameConstraints limits what SANs issued certs may contain

End-Entity Cert

• No CA flag; short validity (90 days–1 year for TLS)

Why Air-Gap the Root?

If the root CA's private key is compromised, an attacker can:

• Issue trusted certificates for any domain
• Issue subordinate CA certs that inherit root trust
• No revocation mechanism can fix this — root certs aren't checked via CRL/OCSP by browsers

Air-gapping + HSM storage makes the attack surface a physical operation:

• Requires presence in a secure facility
• Requires hardware token possession
• Auditable via key ceremony logs

This is why Amazon, DigiCert, etc. use offline root CAs.

Key Ceremony

When you need to use the offline root CA:

1. Transport the HSM to an isolated workstation
2. Multiple trusted operators ("m-of-n" quorum — e.g., 3-of-5 must be present)
3. Generate new intermediate CA cert
4. Sign it with root key
5. Record every action in a written audit log
6. Return HSM to secure storage

This process happens rarely — maybe once every 2–5 years when renewing intermediates.

nameConstraints in Practice

An intermediate CA for your team could have:

nameConstraints:
  permittedSubtrees:
    dNSName: .leo.amazon.com
    iPAddress: 10.0.0.0/8

This means the intermediate can only issue certs with:

• SANs ending in .leo.amazon.com
• IP SANs in the 10.0.0.0/8 range

Any cert attempting to claim api.google.com from this CA → chain validation fails.

For satellite device provisioning: constrain by device type, region, or serial namespace.

Challenge Assignment

Design a PKI hierarchy for Amazon Leo Secure Comms device provisioning:

Write a 2-page design document specifying:

1. Number of CA tiers and rationale
2. Root CA: key algorithm, key size, cert validity, HSM requirements
3. Each intermediate CA: purpose, pathLen, nameConstraints, key algorithm, validity, online/offline
4. End-entity certs: validity period, key algorithm, EKU, who/what gets them
5. Revocation: CRL or OCSP or both, publication frequency, who operates the responder
6. Key ceremony: quorum size, frequency, audit requirements

Reference real CA/B Forum Baseline Requirements where relevant.

Resources

• CA/Browser Forum Baseline Requirements: cabforum.org
• NIST SP 800-57 Part 1: key management recommendations
• NIST SP 800-57 Part 3: PKI-specific guidance
• AWS Private CA documentation (for comparison — Day 35 deep dive)