====== Scenario 1.3: Build Multi-Tier CA Hierarchy ======
**Category:** [[.:start|PKI Infrastructure]] \\
**Complexity:** ⭐⭐⭐⭐ (High) \\
**Prerequisites:** [[.:root_ca_erstellen|1.1 Root CA]], [[.:intermediate_ca_erstellen|1.2 Intermediate CA]] \\
**Estimated Time:** 1-2 Hours
----
===== Description =====
This scenario describes building a **multi-tier PKI hierarchy** with specialized Intermediate CAs for different purposes. A well-structured CA hierarchy enables flexible certificate management, granular security controls, and easy revocation.
**What is created:**
* Root CA (Offline, Trust Anchor)
* Policy CA (optional, for large organizations)
* Multiple specialized Issuing CAs:
* **Server CA:** TLS server certificates
* **Client CA:** mTLS client certificates
* **User CA:** S/MIME and user authentication
* **CodeSign CA:** Code signing certificates
* **Device CA:** IoT/device certificates
**Advantages of a structured hierarchy:**
* **Separation of responsibilities:** Different teams manage different CAs
* **Granular revocation:** A compromised CA only affects one area
* **Compliance:** Different policies per usage purpose
* **Scalability:** New CAs can be easily added
* **Audit:** Clear assignment of certificates to issuing CA
----
===== Hierarchy Models =====
==== Model A: 2-Tier Hierarchy (Standard) ====
┌─────────────────────┐
│ Root CA │
│ (ML-DSA-87) │
│ 20 Years │
│ pathLen=4 │
│ [OFFLINE] │
└──────────┬──────────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ Server CA │ │ Client CA │ │ CodeSign CA │
│ (ML-DSA-65) │ │ (ML-DSA-65) │ │ (ML-DSA-65) │
│ 10 Years │ │ 10 Years │ │ 10 Years │
│ pathLen=0 │ │ pathLen=0 │ │ pathLen=0 │
│ [ONLINE] │ │ [ONLINE] │ │ [HSM] │
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Server Certs │ │ Client Certs │ │ CodeSign │
│ (TLS) │ │ (mTLS) │ │ Certificates │
└──────────────┘ └──────────────┘ └──────────────┘
**Characteristics:**
* Easy to manage
* Root CA signs all Issuing CAs directly
* Suitable for small to medium organizations
==== Model B: 3-Tier Hierarchy (Enterprise) ====
┌─────────────────────┐
│ Root CA │
│ (ML-DSA-87) │
│ 25 Years │
│ pathLen=3 │
│ [OFFLINE/HSM] │
└──────────┬──────────┘
│
┌────────────────────┴────────────────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ Policy CA │ │ Policy CA │
│ (Production) │ │ (Development) │
│ (ML-DSA-65) │ │ (ML-DSA-65) │
│ 15 Years │ │ 10 Years │
│ pathLen=1 │ │ pathLen=1 │
│ [ONLINE/HSM] │ │ [ONLINE] │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
┌─────────────┼─────────────┐ ┌──────────┴──────────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ Server CA │ │ Client CA │ │ CodeSign │ │ Dev CA │ │ Test CA │
│ (Prod) │ │ (Prod) │ │ CA │ │ │ │ │
│ pathLen=0 │ │ pathLen=0 │ │ pathLen=0 │ │ pathLen=0 │ │ pathLen=0 │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Server Client Code Dev Certs Test Certs
Certs Certs Signing
**Characteristics:**
* Higher security through additional layer
* Separation of production and development
* Policy CAs can have different Certificate Policies
* Suitable for large organizations with compliance requirements
==== Model C: Cross-Certification (Multi-Root) ====
┌─────────────────────┐ ┌─────────────────────┐
│ Root CA (Old) │◄──────────────────►│ Root CA (New/PQ) │
│ (RSA/ECDSA) │ Cross-Certificate │ (ML-DSA-87) │
│ [Legacy] │ │ [Post-Quantum] │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
▼ ▼
Legacy Hierarchy PQ Hierarchy
**Characteristics:**
* Enables migration from classical to PQ cryptography
* Both Root CAs are mutually trusted
* Clients can trust both hierarchies
----
===== Flow Diagram =====
┌─────────────────────────────────────────────────────────────────────────────┐
│ CA HIERARCHY SETUP │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 1: Create Root CA (Air-Gapped System) │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Generate ML-DSA-87 key pair │
│ • pathLength = number of planned tiers │
│ • Validity: 20-25 years │
│ • Store key offline │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 2: Plan CA Structure │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Define number and types of Intermediate CAs │
│ • Define naming convention (DN structure) │
│ • Define certificate policies per CA type │
│ • Plan revocation strategy (CRL/OCSP per CA) │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 3: Create Policy CAs (optional, for 3-tier hierarchy) │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Create CSR with pathLength=1 │
│ • Have Root CA sign it │
│ • Assign certificate policy OID │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 4: Create Issuing CAs │
├─────────────────────────────────────────────────────────────────────────────┤
│ For each planned Issuing CA: │
│ a) Generate key pair (ML-DSA-65) │
│ b) Create CSR with specific extensions │
│ c) Have parent CA (Root or Policy CA) sign it │
│ d) Set EKU (Extended Key Usage) according to purpose │
│ e) pathLength=0 (no further Sub-CA) │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 5: Configure Trust Stores and Chains │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Create trust store with Root CA │
│ • Create CA chains for each Issuing CA │
│ • Distribute chains to clients/servers │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 6: Revocation Infrastructure │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Set up CRL Distribution Points for each CA │
│ • Configure OCSP responder │
│ • Publish first (empty) CRLs │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP 7: Documentation and Policies │
├─────────────────────────────────────────────────────────────────────────────┤
│ • Document Certificate Policy (CP) │
│ • Create Certification Practice Statement (CPS) │
│ • Key Ceremony documentation │
│ • Operations manual for CA administrators │
└─────────────────────────────────────────────────────────────────────────────┘
----
===== Involved Functions =====
^ Area ^ FFI Function ^ Description ^
| **Keys** | ''wvds_sec_crypto_x509_keypair_generate_mldsa()'' | ML-DSA keys for CAs |
| **DN** | ''wvds_sec_crypto_x509_dn_create()'' | Distinguished Names |
| **DN** | ''wvds_sec_crypto_x509_dn_add_component()'' | Add CN, O, OU |
| **CSR** | ''wvds_sec_crypto_x509_csr_create()'' | Create CSR |
| **CSR** | ''wvds_sec_crypto_x509_csr_sign()'' | Sign CSR |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_basic_constraints()'' | CA + pathLength |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_key_usage()'' | keyCertSign, cRLSign |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_extended_key_usage()'' | EKU for specialization |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_certificate_policies()'' | Policy OIDs |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_name_constraints()'' | Namespace restrictions |
| **Extensions** | ''wvds_sec_crypto_x509_ext_set_policy_constraints()'' | Policy requirements |
| **Certificate** | ''wvds_sec_crypto_x509_cert_create_from_csr()'' | Issue CA certificate |
| **Chain** | ''wvds_sec_crypto_x509_chain_create()'' | Chain handle |
| **Chain** | ''wvds_sec_crypto_x509_chain_add_cert()'' | Add certificate |
| **Trust Store** | ''wvds_sec_crypto_x509_trust_store_create()'' | Create trust store |
| **Validation** | ''wvds_sec_crypto_x509_validate_chain()'' | Validate chain |
----
===== Recommended Configuration per CA Type =====
==== Root CA ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-87 | Highest security for long-lived trust anchor |
| Validity | 20-25 years | Long-lived, as changes are complex |
| pathLength | Number of tiers | e.g., 4 for flexibility |
| Key Usage | keyCertSign, cRLSign | Only CA operations |
| Storage | Offline/HSM | Highest protection required |
==== Policy CA (optional) ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-65 | Good security/performance ratio |
| Validity | 12-15 years | Shorter than Root |
| pathLength | 1 | Allows one tier below |
| Certificate Policies | Policy OID | Defines issuance policies |
| Storage | Online/HSM | Rare usage, high protection |
==== Server CA ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-65 | Balance security/performance |
| Validity | 8-10 years | Shorter rotation than Root |
| pathLength | 0 | No Sub-CAs allowed |
| Key Usage | keyCertSign, cRLSign | CA operations |
| Extended Key Usage | serverAuth (optional) | Restrict to TLS server |
| Storage | Online (protected) | Frequent use for issuance |
==== Client CA ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-65 | Balance security/performance |
| Validity | 8-10 years | Standard lifetime |
| pathLength | 0 | No Sub-CAs |
| Extended Key Usage | clientAuth | Only client authentication |
| Name Constraints | Optional | DNS/email namespace restrictions |
==== CodeSign CA ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-65 or ML-DSA-87 | High security for code signing |
| Validity | 6-8 years | Shorter rotation recommended |
| pathLength | 0 | No Sub-CAs |
| Extended Key Usage | codeSigning | Only code signing |
| Storage | HSM | Enhanced protection for code signing |
==== Device CA ====
^ Property ^ Recommendation ^ Rationale ^
| Algorithm | ML-DSA-44 or ML-DSA-65 | Performance important for IoT |
| Validity | 8-10 years | Consider device lifetime |
| pathLength | 0 | No Sub-CAs |
| Extended Key Usage | clientAuth, serverAuth | Bidirectional communication |
| Name Constraints | Recommended | Restrict to device namespace |
----
===== Extended Key Usage (EKU) OIDs =====
^ Usage Purpose ^ OID ^ CA Type ^
| TLS Server Authentication | 1.3.6.1.5.5.7.3.1 | Server CA |
| TLS Client Authentication | 1.3.6.1.5.5.7.3.2 | Client CA, Device CA |
| Code Signing | 1.3.6.1.5.5.7.3.3 | CodeSign CA |
| Email Protection (S/MIME) | 1.3.6.1.5.5.7.3.4 | User CA |
| Time Stamping | 1.3.6.1.5.5.7.3.8 | TSA CA |
| OCSP Signing | 1.3.6.1.5.5.7.3.9 | OCSP Responder |
**EKU Inheritance:** If a CA has an EKU, issued certificates may only have EKUs that are a subset of the CA's EKUs. A Server CA with only ''serverAuth'' cannot issue certificates with ''clientAuth''.
----
===== Name Constraints =====
Name Constraints restrict the namespace in which a CA may issue certificates.
wvds_sec_crypto_x509_ext_set_name_constraints(
ext,
permitted_dns: ["datecpro.de", ".datecpro.de"],
permitted_email: ["@datecpro.de"],
excluded_dns: ["external.datecpro.de"],
critical: true
)
----
{{tag>scenario pki hierarchy root-ca intermediate-ca policy-ca eku name-constraints}}
----
//Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional//