Architecture.

Spork is organized as a Cargo workspace of focused crates. All CA operations flow through spork-core; no bypass paths exist at the CLI or API layer. The only C dependency is vendored SQLite — the rest of the stack, including TLS via rustls, is Rust. Binaries are dynamically linked against glibc 2.35+; glibc is the only system runtime dependency.

Crate layers

Layer	Crates
CLI / UI	`spork-shell` — interactive TUI shell `spork-tui` — terminal UI components `spork-cli` — command-line interface
Protocol servers	`spork-acme` — ACME server (RFC 8555) `spork-est` — EST server (RFC 7030) `spork-scep` — SCEP server (RFC 8894) `spork-ocsp` — OCSP responder (RFC 6960)
Core CA	`spork-core` — CA operations, policy enforcement, audit logging `spork-crypto` — key management and signing operations `spork-crl` — CRL generation and lifecycle `spork-ceremony` — key ceremony workflows
API	`spork-api` — REST API `spork-web` — web admin dashboard
Storage	`spork-db` — storage abstraction (SQLite default) `spork-ldap` — LDAP / Active Directory integration
Infrastructure	`spork-hsm` — HSM abstraction (SoftHSM, PKCS#11) `spork-scheduler` — task scheduling (CRL regen, expiry checks) `spork-notify` — expiry notifications `spork-license` — license management `spork-common` — shared types and utilities
Client tools	`spork-probe` — TLS probing and PQC detection `spork-client-output` — output formatting (text, JSON, PEM)
Distribution	`spork-packager` — package builder `spork-installer` — self-extracting installer with SHA3-256 + Ed25519

Issuance flow

A certificate request passes through four stages, all validated inside spork-core before the signing key is touched.

1. Request      CSR + named profile (tls-server, code-sign, …)
2. Validation   spork-core: subject DN, key type, name constraints, path length, EKU policy
3. Signing      spork-crypto: load CA key, compute TBS hash, generate signature
4. Output       X.509 DER/PEM — serial, subject, validity, extensions stored in DB; audit log written

Storage

Backend	Status	Notes
SQLite	alpha	Default. Single file, no external service. Lab and small deployments.
PostgreSQL	planned	Replication, connection pooling. Required for high availability.

Security model

Property	Implementation
Isolation	CLI and API are thin wrappers. All policy and crypto enforced in `spork-core`. No bypass paths.
Key protection	Private keys encrypted at rest. Never exposed outside `spork-crypto`. HSM support roadmapped.
Audit trail	Every operation logged: timestamp, operator, serial, action. JSON format for SIEM ingestion.
Constraints	Name constraints, path length, and EKU enforced at issuance. Invalid CSRs rejected before signing.

Key dependencies

Cryptographic primitives come from the RustCrypto project. These implementations have not yet had an independent third-party audit; see the known limitations section on the main Spork page.

Crate	Role
`p256`, `p384`, `rsa`	Classical signature algorithms (ECDSA P-256 / P-384, RSA)
`ml-dsa`	ML-DSA-44 (category 2), ML-DSA-65 (category 3), ML-DSA-87 (category 5) — FIPS 204
`slh-dsa`	SLH-DSA-SHA2-128s / 192s / 256s — FIPS 205
`ed25519-dalek`	Ed25519 signatures (installer signing only; RFC 8032, not FIPS)
`rustls`	TLS implementation for the ACME server and probe tools
`x509-cert`, `der`	Certificate and ASN.1 DER encoding / decoding
SQLite (vendored C)	Default storage backend — the only C dependency