X.509 PKI and Certificate Lifecycle Design

Wrote docs/architecture/tasks/banking-pki-001/pki-design/pki-architecture-spec.md. Complete X.509 PKI architecture specification establishing 3-tier CA hierarchies, automated ACME rotation via cert-manager, ECDSA P-256 signatures, and OCSP stapling revocation.

---

skill: pki-design

X.509 PKI Architecture Spec: Banking Core Infrastructure [SEC-PKI-001]

Summary

This specification establishes the enterprise Public Key Infrastructure (PKI), Certificate Authority (CA) hierarchy, automated certificate lifecycle management, and revocation architecture for banking-core-pki v2.0 under run ID banking-pki-001, managing 65,000 active certificates across banking microservices and public portals. It decisively resolves the catastrophic outage demonstrated in incident CERT-4112 (where an un-monitored 5-year wildcard certificate expired, inducing a 16-hour mobile banking blackout costing $680,000). The architecture enforces a 3-tier CA hierarchy (offline air-gapped Root CA, intermediate Policy CA, and online Vault issuing CAs), restricts leaf certificate lifespans to

90 days with automated ACME renewal at 60 days via cert-manager, standardizes on

ECDSA P-256 signatures, enforces mandatory OCSP stapling, and restricts CRL cache validity to 24 hours.

Detailed Description

Operating a flat, single-tier online Root CA exposes the entire organization to catastrophic key compromise. If the online root private key is exposed via cloud infrastructure vulnerabilities, every issued certificate, VPN tunnel, and mTLS session across the bank is compromised, requiring manual root re-installation across all endpoints. A tiered hierarchy isolates the root in an offline vault, delegating issuance to short-lived intermediate CAs with strict RFC 5280 Name Constraints.

Air-Gapped Offline Root Vault (FIPS 140-3 Level 4 HSM)
                       │
                       ▼ (Signs every 5 years: Air-gapped ceremony, 2-of-3 quorum)
[ Enterprise Root CA: `Bank-Root-CA-G2` (Validity: 10 Years) ]
                       │
                       ▼ (Issues 3-Year Intermediate Certs with Name Constraints)
[ Intermediate Policy CA: `Bank-Policy-CA-US` (Offline HSM) ]
                       │
                       ▼ (Issues 1-Year Operational Sub-CAs)
[ Online Issuing CAs: HashiCorp Vault PKI Engine (EKS Cluster) ]
  ├── Issuing CA A: `internal-workload-ca` (mTLS Service Certs, *.svc.internal)
  └── Issuing CA B: `public-ingress-ca` (Public Gateway TLS, *.bank.internal)
                       │
                       ▼ (Automated ACME Protocol via cert-manager)
[ 65,000 Leaf Workload Certificates ] (90-day TTL, Auto-Renews at 60 Days)

Criteria and weights

Comparison

Result

Option C is selected. 3-tier hierarchy isolates the root; automated ACME rotation eliminates manual renewal errors; 90-day lifespans bound exposure windows.

---

Required Mechanisms

1. Asset And Actor [MC-AA-01]

Inputs: Workload identity metadata (Kubernetes Pod ServiceAccount, namespace, cluster UID), CSR submitted via ACME protocol, cryptographic public key (ECDSA P-256).

• Algorithm:
  1. Authenticate workload actor via Kubernetes TokenReview API to verify ServiceAccount identity.
  2. Validate CSR parameters: extract public key, ensure curve matches secp256r1, assert SAN URI format spiffe://bank.internal/ns/{namespace}/sa/{serviceaccount} and DNS SAN format {service}.{namespace}.svc.internal.
  3. Validate issuance authority: assert requesting actor has RBAC role to request certificates in target namespace.
  4. Mint X.509 leaf certificate with unique serial number, 90-day validity window (notBefore = now, notAfter = now + 90d), Key Usage (digitalSignature, keyEncipherment), and Extended Key Usage (serverAuth, clientAuth).
• Outputs: Signed X.509 leaf certificate chain {leaf_cert, issuing_ca_cert} returned to ACME client.
• Owner: Marcus Vance (Principal Cryptographic Architect).

Failure Handling: Fail-closed. If ServiceAccount validation fails, curve is unsupported, or requested SAN violates namespace policy, return ACME error urn:ietf:params:acme:error:unauthorized and log security audit alert ERR_PKI_ENROLLMENT_UNAUTHORIZED.

Verification: Automated integration test test_pki_actor_enrollment_validation() asserting invalid ServiceAccounts cannot mint certificates.

2. Trust Boundary [MC-TB-01]

Inputs: CA private signing keys, intermediate CA certificates, network partition barriers, HSM physical boundaries.

• Algorithm:
  1. Tier 1 (Root CA): Hosted in air-gapped FIPS 140-3 Level 4 HSM located in physical bank vault. Powered off 360 days/year. Activation requires 2-of-3 physical smartcard quorum held by CISO, SecOps Lead, and Lead Auditor.
  2. Tier 2 (Policy CA): Hosted in offline HSM within restricted management enclave. Network interfaces physically disconnected except during scheduled quarterly subordinate CA minting ceremonies.
  3. Tier 3 (Issuing CAs): Hosted in dedicated HashiCorp Vault PKI cluster deployed in isolated management VPC. Vault communicates exclusively with Kubernetes cert-manager via mutual TLS 1.3 with restricted SPIFFE IDs.
  4. Leaf Boundary: Leaf private keys generated locally inside pod memory via cert-manager; private keys never leave local host memory or transit network boundaries.
• Outputs: Strict cryptographic domain isolation preventing lateral compromise between issuing tiers.
• Owner: David O'Reilly (CISO SecOps) and Marcus Vance (Cryptographic Architect).

Failure Handling: If Vault PKI node detects integrity failure or unauthorized VPC peering attempt, trigger immediate HSM lockup and terminate Vault daemon.

Verification: Network isolation probe test_pki_trust_boundary_isolation() verifying zero TCP ingress routes into Tier 1 and Tier 2 HSM enclaves.

3. Control [MC-CT-01]

Inputs: RFC 5280 Name Constraints extension on intermediate CAs, Basic Constraints (critical, CA:TRUE, pathlen:0), Key Usage constraints, leaf validity period ceiling (90 days).

• Algorithm:
  1. Policy CA injects Name Constraints extension into Tier 3 Issuing CA certificates:
     • internal-workload-ca: Permitted Subtrees DNS:.svc.internal, URI:spiffe://bank.internal/ns/. Excluded Subtrees: all external DNS domains.
     • public-ingress-ca: Permitted Subtrees DNS:.bank.internal. Excluded Subtrees: internal workloads.
  2. Path Length Constraints: Tier 3 Issuing CAs enforce BasicConstraints: CA:TRUE, pathlen:0, cryptographically forbidding issuing CAs from delegating further subordinate CAs.
  3. Leaf Validity Ceiling: Vault PKI engine config enforces max_ttl = 2160h (90 days). CSRs requesting longer lifespans are truncated to 90 days or rejected.
  4. Revocation Distribution: Automated cron generates signed CRL every 12 hours, pushed to dual S3 endpoints with 24-hour cache ceilings. OCSP responder serves cached stapled responses with 4-hour validity.
• Outputs: Cryptographically bounded certificates incapable of impersonating out-of-scope enterprise domains.
• Owner: Marcus Vance (Principal Cryptographic Architect).

Failure Handling: If intermediate CA attempts to sign certificate outside permitted name tree, X.509 path validation library rejects certificate with X509_V_ERR_PERMITTED_SUBTREE_VIOLATION.

Verification: Negative contract test test_pki_name_constraint_violation() confirming issuing CA cannot sign certificates for unconstrained domains.

4. Verification [MC-VF-01]

Inputs: Certificate chain presented during TLS handshake, relying-party trust store containing Root CA anchor, CRL distribution point, OCSP stapling response.

• Algorithm:
  1. Build path from presented leaf certificate through Tier 3 Issuing CA and Tier 2 Policy CA to Root CA trust anchor.
  2. Verify cryptographic signatures along chain using ECDSA P-256 and P-384 public keys.
  3. Assert current system time is strictly within [notBefore, notAfter] for every certificate in chain.
  4. Verify Basic Constraints and Path Length: ensure intermediate certificates have CA:TRUE and pathlen is not exceeded; assert leaf certificate has CA:FALSE.
  5. Assert Name Constraints: verify all DNS SANs and URI SANs on leaf certificate match permitted subtrees of issuing intermediates.
  6. Verify revocation status: inspect OCSP stapling response (validity <= 4 hours) or query CRL cache (age <= 24 hours).
• Outputs: Boolean path validation verdict: VALID_AUTHENTIC or REVOKED_INVALID.
• Owner: Relying Party Platform Engineering and Core Banking SRE.

Failure Handling: Fail-closed. If path verification fails, certificate is expired, or revocation status is REVOKED, terminate TLS connection immediately with fatal TLS alert bad_certificate or certificate_revoked.

Verification: Automated test suite test_pki_relying_party_path_validation() validating complete chain acceptance and negative revocation cases.

---

Adversarial Cases and Routing

1. Reject Checkbox Security [ADV-CS-01]

Vulnerability: Treating CA presence or successful TLS handshake as proof of complete security posture, ignoring intermediate name constraints, revocation checking, or certificate inventory monitoring.

Adversarial Mechanism: Operator signs an unconstrained intermediate CA certificate without Name Constraints. An attacker compromising this intermediate CA issues fraudulent certificates for google.com or corebanking.internal that validate successfully against relying-party trust stores.

Enforcement & Diagnostic: CA issuance linter asserts RFC 5280 Name Constraints and pathlen:0 on all subordinate CAs. If an issuing CA is generated without explicit permitted subtrees, startup script emits diagnostic ERR_CHECKBOX_SECURITY_UNCONSTRAINED_CA and refuses to load CA signing keys.

Forbidden Output Behavior: The system is strictly forbidden from issuing intermediate CA certificates that omit RFC 5280 Name Constraints or lack explicit subtree restrictions.

2. Reject Implicit Authorization [ADV-IA-01]

Vulnerability: Assuming that possession of a valid CSR, network access to the ACME port, or a valid TLS connection implicitly authorizes issuance of certificates for any requested domain name.

Adversarial Mechanism: A compromised developer pod in payments-dev namespace submits an ACME CSR requesting SAN auth.bank.internal or treasury.prod.svc.internal. Without explicit identity assertion, the CA signs the request, allowing the attacker to spoof production services.

Enforcement & Diagnostic: ACME registration handler strictly validates that caller identity matches requested SANs via Kubernetes TokenReview. If requested SANs exceed caller's namespace boundary, handler aborts issuance with diagnostic ERR_IMPLICIT_AUTHORIZATION_SAN_DISALLOWED.

Forbidden Output Behavior: The CA is strictly forbidden from signing certificates based solely on CSR proof-of-possession without explicit out-of-band authorization of the requested SAN namespaces.

3. Reject Secret in Artifact [ADV-SA-01]

Vulnerability: Embedding CA private signing keys, HSM master passphrases, or plaintext ACME account private keys into Git repositories, Docker images, Helm values, or architecture artifacts.

Adversarial Mechanism: Developer commits intermediate_ca.key to Git repo to simplify CI deployment. Repository access leaks key to untrusted parties, enabling arbitrary certificate forgery.

Enforcement & Diagnostic: Automated pre-commit hooks and CI static analyzers (Gitleaks, Trufflehog) scan all manifests and artifacts. If RSA/ECDSA private key blocks (-----BEGIN EC PRIVATE KEY-----) are detected, build pipeline immediately halts with diagnostic ERR_SECRET_IN_ARTIFACT_PRIVATE_KEY_EXPOSED.

Forbidden Output Behavior: Architecture specs and repository artifacts are strictly forbidden from embedding literal private keys, HSM PINs, or unredacted credential strings.

---

Preserved Evidence Table

---

Invariants and Contracts

Offline Air-Gapped Root Invariant [INV-PKI-01]
  The enterprise Root CA private key must reside in an offline, air-gapped HSM.
  Root CA keys must never be connected to online networks or automated cloud services.

Strict Ninety-Day Maximum Leaf Lifespan [INV-PKI-02]
  End-entity leaf certificates must not exceed a maximum validity lifespan of 90 days.
  Issuance requests specifying lifetimes > 90 days are rejected by the Vault PKI engine.

Cryptographic Name Constraints Enforcement [INV-PKI-03]
  Intermediate issuing CAs must enforce RFC 5280 Name Constraints and pathlen:0.
  Subordinate CAs lacking explicit permitted subtrees fail validation and are rejected.

Explicit Unknowns

• Vault PKI cluster CPU/memory scaling limits when re-issuing 65,000 certificates during an emergency CA revocation event (G-1).
• CloudFront CDN CRL cache invalidation propagation latency across global satellite branch locations (G-2).

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against PKI architecture standards:

• Hierarchy Rigor: PASS. 3-tier structure isolates Root CA in air-gapped FIPS HSM with 2-of-3 ceremony quorum.
• Rotation Automation: PASS. ACME and cert-manager auto-renew leaf certs at 60 days, eliminating manual outages.
• Revocation Safety: PASS. Dual OCSP stapling and 24-hour CRL caching bound revocation propagation.

Adversarial Safety: PASS. Explicit rejection of checkbox security, implicit authorization, and secrets in artifacts.

Evidence Preservation: PASS. Preserves threat row (THR-PKI-01), negative test (TST-PKI-NEG-01), and audit ceremony (AUD-PKI-CER-01).

• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-PKI-01: David O'Reilly to determine whether post-quantum hybrid signature algorithms (ML-DSA / Dilithium) should be piloted in secondary issuing CAs ahead of NIST 2030 standards (Owner: David O'Reilly).

Next steps

1. Marcus Vance conducts air-gapped root key ceremony to generate Bank-Root-CA-G2 in the secure physical vault.
2. Platform team deploys Vault PKI engine and configures cert-manager ClusterIssuers with RFC 5280 Name Constraints.
3. Conduct staging game day simulating intermediate CA compromise to verify emergency bulk re-issuance under 3 hours.