Inhaltsverzeichnis

Scenario 1.3: Build Multi-Tier CA Hierarchy

Scenario 1.3: Build Multi-Tier CA Hierarchy

Category: PKI Infrastructure
Complexity: ⭐⭐⭐⭐ (High)
Prerequisites: 1.1 Root CA, 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
)

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

Inhaltsverzeichnis

Scenario 1.3: Build Multi-Tier CA Hierarchy

Description

Hierarchy Models

Model A: 2-Tier Hierarchy (Standard)

Model B: 3-Tier Hierarchy (Enterprise)

Model C: Cross-Certification (Multi-Root)

Flow Diagram

Involved Functions

Recommended Configuration per CA Type

Root CA

Policy CA (optional)

Server CA

Client CA

CodeSign CA

Device CA

Extended Key Usage (EKU) OIDs

Name Constraints

Seiten-Werkzeuge