How SPORK CA Works

SPORK is a Certificate Authority built entirely in Rust. It handles the full certificate lifecycle: key generation, certificate issuance, revocation, and distribution. This page explains its architecture, protocols, and security model.

Architecture Overview

SPORK uses a 3-tier PKI hierarchy: Root CA, Policy CAs, and Issuing CAs. This separation allows the Root CA key to remain offline while Issuing CAs handle day-to-day certificate operations.

Root CA (offline, P-384, 25-year validity)
  |
  +-- Policy CA (per-domain, P-384, 10-year)
        |
        +-- Issuing CA (operational, P-256, 5-year)
              |
              +-- End-entity certificates (TLS, code signing, etc.)

Declarative Hierarchy Builder

CA hierarchies are defined in TOML configuration files and built with spork pki:

# hierarchy.toml
[root]
common_name = "SPORK Root CA"
algorithm = "ecdsa-p384"
validity_years = 25

[[policy_cas]]
common_name = "SPORK TLS Policy CA"
algorithm = "ecdsa-p384"
validity_years = 10

  [[policy_cas.issuing_cas]]
  common_name = "SPORK TLS Web Server Issuing CA"
  algorithm = "ecdsa-p256"
  validity_years = 5

# Validate, preview, and build
spork pki validate hierarchy.toml
spork pki preview hierarchy.toml
spork pki build hierarchy.toml --output /opt/spork/pki

Storage

All CA state is stored in PostgreSQL: certificates, keys (encrypted), revocation lists, ACME accounts/orders, audit logs. The installer bundles PostgreSQL and configures it automatically.

Certificate Lifecycle

Enrollment Protocols

SPORK supports four certificate enrollment protocols. Choose based on your use case:

Post-Quantum Cryptography

SPORK supports NIST's post-quantum standards alongside classical algorithms. Enable with --features pqc at build time.

Migration Strategy

Rather than an abrupt switchover, SPORK supports hybrid certificates that combine a classical signature with a post-quantum signature. This provides backwards compatibility: classical clients verify the ECDSA signature, PQC-aware clients verify both.

# Issue a hybrid certificate
spork cert issue --ca "TLS Issuing CA" \
  --cn "server.example.com" \
  --algorithm ml-dsa-65-p256 \
  --type tls-server

Security Model

Admin Certificate Hierarchy

All administrative operations require mutual TLS authentication. Four privilege levels control access:

Key Protection

• At rest: All private keys encrypted with AES-256-GCM. Key encryption key derived from passphrase using Argon2id (memory-hard KDF).
• In transit: TLS 1.2/1.3 for all network operations. No plaintext key material leaves the server.
• Installer integrity: Every installer binary contains a SHA3-256 hash of its payload. Optional Ed25519 signature verification.

FIPS 140-3 Mode

FIPS 140-3 is enabled by default using aws-lc-rs (NIST Certificate #4816) as the cryptographic backend. Non-FIPS pure Rust mode is available via runtime toggle.

Installer System

SPORK packages are distributed as self-extracting ELF binaries. Each installer is a single file that contains all binaries, configuration templates, systemd units, and the PostgreSQL database engine.

# Download and run
curl -sSLO https://example.com/spork-ca-0.3.0-beta.7-linux-x86_64-installer
chmod +x spork-ca-0.3.0-beta.7-linux-x86_64-installer

# Verify integrity before installing
./spork-ca-0.3.0-beta.7-linux-x86_64-installer --verify

# Install (runs setup wizard)
sudo ./spork-ca-0.3.0-beta.7-linux-x86_64-installer

The spork-setup wizard runs after extraction and handles:

• PostgreSQL initialization and schema creation
• CA key generation and certificate issuance
• TLS certificate for admin interfaces
• systemd service configuration
• Firewall port suggestions

ACME Server

The ACME server implements RFC 8555 and is compatible with standard ACME clients:

Challenge Types

Windows IIS Integration

The built-in ACME client can deploy certificates directly to Windows IIS:

spork acme issue \
  --server https://acme.example.com/directory \
  --domain www.example.com \
  --deploy iis \
  --iis-site "Default Web Site"

This handles the full pipeline: ACME challenge, certificate issuance, PFX conversion, IIS binding update, and HTTPS verification.

Code Signing

The spork-sign package provides CMS/PKCS#7 code signing and Authenticode signature capabilities:

• CMS signatures: Sign files with detached or embedded PKCS#7 signatures
• Authenticode: Sign Windows PE executables and DLLs
• Timestamps: RFC 3161 time-stamp authority for long-term signature validity
• Verification: Verify signatures and timestamp chains

# Sign a binary
spork sign code --key signing-key.pem --cert signing-cert.pem --input app.exe --output app-signed.exe

# Timestamp a signature
spork sign tsa --url http://tsa.example.com/tsa --input signature.p7s

WebUI

SPORK includes a web-based admin dashboard built with Axum and server-rendered HTML. It provides:

• Certificate browser: Search, filter, and inspect all issued certificates
• CA status: View all CAs in the hierarchy, their validity, and key status
• Revocation management: View CRL status and OCSP responder health
• ACME dashboard: Monitor ACME accounts, orders, and challenge status
• Audit log: Full audit trail of all operations
• Protocol configuration: Configure ACME, EST, SCEP, OCSP, LDAP, HSM, and webhook settings

Access is controlled via mTLS (admin certificate required) or session-based login. Destructive operations always require mTLS.

Ceremony System

For high-assurance CA operations, SPORK includes a formal ceremony framework modeled after enterprise CAs like Entrust and DigiCert. Key ceremonies ensure that critical operations (root key generation, CA signing) happen under multi-party control.

15 Ceremony Action Types

N-of-M Key Sharing (Shamir Secret Sharing)

Root CA keys can be split into M shares where any N shares are sufficient to reconstruct the key. For example, a 3-of-5 scheme means 5 key custodians each hold a share, and any 3 must be present to use the root key.

# In a ceremony plan:
[[actions]]
type = "CreateKeyShares"
key_id = "root-ca"
threshold = 3    # N shares needed
total_shares = 5 # M total shares

Each ceremony produces an encrypted ceremony file with a complete audit trail: who participated, what actions were taken, timestamps, and verification hashes. The ceremony verifier can independently validate the entire ceremony log.

Note: The ceremony library is complete. CLI integration is planned for a future release. Currently, CA setup uses spork pki for declarative hierarchy building.