This Certification Practice Statement ("CPS") describes the practices of the Sunlit Bytes Certificate Authority (the "CA"), a private public-key infrastructure operated by ZDN Enterprises, LLC ("the Operator", doing business as Sunlit Bytes) under IANA Private Enterprise Number 66538. The CA issues certificates for document signing, data-at-rest encryption, personal and device identity, S/MIME, and SSH access, primarily in support of the Sunlit Workshop provenance system. This document follows the framework of RFC 3647.
This is a private-trust PKI. Its root certificate is not included in any browser, operating-system, or application trust store, and the CA makes no claim of conformance to CA/Browser Forum Baseline Requirements or WebTrust/ETSI audit schemes. Relying parties install the root deliberately and rely on it at their own judgment (§9).
This CPS is identified by OID 1.3.6.1.4.1.66538.2.0. The OID arc
assignments under the Operator's PEN are:
| OID | Assignment |
|---|---|
1.3.6.1.4.1.66538 | ZDN Enterprises, LLC (base arc) |
…66538.1.1 | Sunlit Bytes TSA timestamp policy, v1 (see the TSA policy statement) |
…66538.2.0 | This Certification Practice Statement |
…66538.2.1 | Certificate policy: document signing |
…66538.2.2 | Certificate policy: provenance data-at-rest encryption |
…66538.2.3 | Certificate policy: user TLS-client (mTLS) identity |
…66538.2.4 | Certificate policy: S/MIME (signing and encryption) |
…66538.2.5 | Certificate policy: device identity |
…66538.2.6 | Certificate policy: delegated OCSP responder |
…66538.2.7 | Certificate policy: internal TLS server |
…66538.2.8 | Certificate policy: Sunlit Workshop item authenticity |
…66538.3, …66538.4 | Reserved (private extensions; non-X.509 uses) |
Timestamp tokens issued before 2026-08-14 carry the interim policy OID
2.25.312690151706139119217803799449385446861; they remain valid.
No X.509 certificates were ever issued under the interim arc.
Certification authorities. One offline root
("Sunlit Bytes Root CA", self-signed, valid to 2051) and four online issuing
CAs, each constrained to a single tier (pathLenConstraint=0):
Document CA 1, Encryption CA 1, Identity CA 1, and Device CA 1 (all valid to
2036). Two Ed25519 SSH CAs (user and host) operate in parallel outside X.509.
A separate root-issued leaf operates the RFC 3161 timestamping authority.
Subscribers. The Operator, Sunlit Bytes infrastructure and services, workshop devices and, prospectively, Sunlit Workshop customers.
Relying parties. Anyone who chooses to install the Sunlit Bytes root and validate signatures, identities, or timestamps against it — typically recipients of Sunlit Workshop certificates of authenticity and provenance records.
Permitted uses are defined per profile (§7). Certificates are not intended for, and must not be relied upon for, publicly-trusted TLS, financial transactions, or any use requiring an audited CA.
This CPS is administered by the Operator. Questions and revocation requests: zach@sunlitbytes.com. The Operator may amend this CPS at any time; the current version is always the one published at the canonical URL, and material changes increment the version number.
The CA repository is served from ca.sunlitbytes.com (also
reachable at tsa.sunlitbytes.com):
| Resource | URL |
|---|---|
| Root certificate | /ca/roots.pem |
| Issuing-CA certificates | /ca/certs/{doc1,enc1,id1,dev1}.pem (PEM, with chain) and .der |
| Issued end-entity certificates | /ca/certs/<serial>.pem (certificates are public artifacts) |
| CRLs | /crl/{doc1,enc1,id1,dev1}.crl; root ARL at /crl/root.crl |
| OCSP | /ocsp (RFC 6960, GET and POST) |
| SSH CA public keys | /ca/ssh/user-ca.pub, /ca/ssh/host-ca.pub |
| This CPS | /cps.html |
| TSA policy | /policy |
Revocation and AIA resources are intentionally reachable over plain HTTP, as required by common validation software; browser-facing pages redirect to HTTPS. CRLs for the online CAs are reissued at least daily and immediately upon any revocation; the offline-signed root ARL is reissued at least annually.
Subject names use the form C=US, O=Sunlit Bytes, CN=<name>.
Subject alternative names are constrained by profile: S/MIME and user-identity
certificates carry exactly one rfc822Name; device certificates
carry a dNSName of the form
<device-id>.devices.sunlitbytes.com and a URI of the form
urn:sunlit:device:<device-id> derived from the CN. Names are
not guaranteed unique across time; the certificate serial number is the
authoritative identifier.
All issuance is authenticated by one of:
| Path | Authentication | Identity vetting |
|---|---|---|
| Administrative issuance (API, CLI, web console) | Operator-held bearer secret | Personal knowledge of the Operator; the Operator asserts the subject information |
| Enrollment tokens | Single-use (or bounded-use), profile-pinned, time-limited tokens minted by the Operator; optionally restricted to a CN pattern | The act of delivering the token to a known recipient constitutes vetting |
No third-party identity verification (documents, domain control, etc.) is performed. Relying parties should treat subject information as an assertion by the Operator.
Issuance is exclusively CSR-based (PKCS #10). The CA verifies the CSR self-signature, requires the key type mandated by the profile (ECDSA P-256), and takes only the CN and — where the profile permits — SAN values from the request; every other certificate field and extension is imposed by the profile (§7). Subscriber key pairs are generated by the subscriber (locally in the CLI, or in the subscriber's browser for web issuance and enrollment). The CA never generates, receives, or stores subscriber private keys, with one deliberate exception: the provenance-encryption key pair is generated by the Operator in an offline ceremony and escrowed with the root key materials, because encrypted data must remain recoverable beyond any certificate's lifetime (§6.2).
An active certificate already existing for the same public key and profile causes the request to be refused unless replacement is explicitly requested, in which case the prior certificate is revoked as superseded.
Item authenticity certificates. For each finalized
Sunlit Workshop serial, the provenance service requests a
provenance-item certificate using a credential scoped to the
per-serial profiles. The item key pair is generated by the provenance service;
the private key is stored only encrypted to the provenance-encryption
certificate (recoverable solely via the escrowed key, §6.2). Certificates
are revoked when a serial is unfinalized or its item is reported stolen or
destroyed, so relying parties can check live authenticity status via CRL
or OCSP.
This identity certificate is the piece's anchor: the SHA-256 of its DER is bound into the signed COSE record carried on the piece's certificate NFC tag, and its private key never exists outside that escrow. It therefore does not sign documents, and asserts no key usage that would suggest otherwise.
Item signing certificates. A separate
provenance-item-sign certificate, same subject and same item URIs
under the same policy, signs that serial's certificate of authenticity. Its key
pair is distinct from the identity key and is held online by the provenance
service, because a certificate of authenticity is re-rendered whenever the
record it states changes and must be re-signed each time; keeping the two apart
is what allows the anchor key to stay offline for the life of the piece. It
carries contentCommitment and id-kp-documentSigning, the key usage
a document signature requires. Both certificates for a serial are issued and
revoked together, so revoking a piece revokes the signature on its certificate
of authenticity with it.
Renewal is re-issuance with a new key (re-key). Certificates are not renewed with the same key past the profile's validity limit.
The Operator may revoke any certificate at any time. Subscribers and relying parties may request revocation by contacting the Operator (§1.5); requests asserting key compromise are honored immediately. Standard RFC 5280 reason codes are recorded. Upon revocation the affected CRL is regenerated synchronously, and OCSP reflects the revocation immediately. Certificates remain listed on CRLs until one full CRL cycle after their natural expiry. Suspension (certificateHold with restoration) is not practiced.
OpenSSH certificates (user ≤ 30 days, host ≤ 366 days) are not revocable once issued; short lifetimes are the compensating control. Serial numbers are monotonic and every issuance is recorded in the audit log.
The CA is operated by a single natural person (the Operator's principal). There is no multi-person control; this is an accepted limitation of a private PKI at this scale and is disclosed here so relying parties can weigh it.
The root key was generated in an offline ceremony using published, version-controlled ceremony scripts, and is stored only as an encrypted PKCS #8 file in the Operator's password manager and on offline media; it is never present on network-connected service infrastructure. Issuing-CA certificates, SSH CAs, the root ARL, and the escrowed provenance-encryption key are produced in like ceremonies. Online issuing-CA private keys are provisioned to the hosting platform (Fly.io) as runtime secrets; the Device CA key is withheld offline until device issuance is activated.
Every issuance, revocation, enrollment-token event, and SSH signing is written to an append-oriented audit table with actor, target, timestamp, and detail, and is reviewable through the administrative console. TSA token issuance is separately serialised and logged.
CA databases reside on a platform volume with scheduled snapshots. Public certificates, chains, and ceremony scripts are version-controlled. Loss of the service host does not affect the root; issuing CAs can be redeployed from secrets and repository state.
On suspected compromise of an issuing-CA key: the CA is revoked on the root ARL (offline ceremony), affected subscribers re-issued under a successor CA, and an incident notice published on the repository site. On suspected root compromise: the hierarchy is abandoned and rebuilt; relying parties are notified to remove the root. Sunlit Workshop provenance artifacts additionally carry independent proofs (a public TSA and OpenTimestamps anchoring), so relying parties never depend solely on this hierarchy.
| Key | Algorithm | Signature |
|---|---|---|
| Root CA | ECDSA P-384 | ECDSA-with-SHA384 |
| Issuing CAs | ECDSA P-256 | signed with SHA-384 by the root; sign leaves with SHA-256 |
| End-entity certificates | ECDSA P-256 | ECDSA-with-SHA256 |
| SSH CAs | Ed25519 | Ed25519 |
| TSA tokens | ECDSA P-256 | ECDSA-with-SHA256; SHA-256/384/512 imprints accepted (SHA-1 and MD5 refused) |
No hardware security modules are used; this is disclosed as a known limitation. Offline keys are encrypted at rest and stored in the Operator's password manager and on offline media. Online keys exist as hosting-platform secrets injected into a single service instance. The escrowed provenance-encryption private key is retained indefinitely — certificate expiry or revocation never triggers key destruction, because ciphertext outlives certificates. Data encrypted to the provenance-encryption certificate uses ephemeral-static ECDH with HKDF-SHA256 and AES-256-GCM; the encrypting service holds only the public certificate and cannot decrypt.
The CA service runs as a single-purpose application; administrative endpoints require a bearer secret over TLS; public endpoints are rate-limited. The repository, issuance API, OCSP responder, and TSA share one deployment; its health checks fail if revocation data goes stale.
All end-entity certificates include: basicConstraints CA:FALSE
(critical), a critical keyUsage as below, SKI/AKI, a
certificatePolicies OID from §1.2, an AIA pointing at
http://ca.sunlitbytes.com/ocsp and the issuing-CA certificate,
and a CRL distribution point — except OCSP responder certificates, which carry
id-pkix-ocsp-nocheck and deliberately no revocation pointers.
| Profile | Policy OID | Max validity | Key usage (critical) | EKU | SAN |
|---|---|---|---|---|---|
| doc-signing | …2.1 | 3 years | digitalSignature, contentCommitment | id-kp-documentSigning | optional rfc822 |
| provenance-encryption | …2.2 | 5 years | keyAgreement only | — | — |
| user-mtls | …2.3 | 1 year | digitalSignature | clientAuth | rfc822 required |
| smime-sign | …2.4 | 2 years | digitalSignature, contentCommitment | emailProtection | rfc822 required |
| smime-encrypt | …2.4 | 2 years | keyAgreement | emailProtection | rfc822 required |
| device | …2.5 | 2 years | digitalSignature | clientAuth | dNSName + URN from device id |
| provenance-item | …2.8 | 5 years | digitalSignature | — | URN + verify-URL URIs from the provenance serial |
| provenance-item-sign | …2.8 | 5 years | digitalSignature, contentCommitment | id-kp-documentSigning | URN + verify-URL URIs from the provenance serial |
| ocsp-responder | …2.6 | 30 days | digitalSignature | id-kp-OCSPSigning (critical) + ocsp-nocheck | — |
| tls-server (internal) | …2.7 | 1 year | digitalSignature | serverAuth, clientAuth | internal dNSNames |
Issuing CAs carry basicConstraints CA:TRUE, pathLen 0
(critical), keyUsage keyCertSign, cRLSign, digitalSignature
(critical), no EKU, and point to the root ARL. Serial numbers are random with
at least 64 bits of entropy.
CRLs are DER, signed by the issuing CA, with monotonic
cRLNumber, AKI, entry reason codes, thisUpdate at
generation and nextUpdate seven days later (root ARL: twelve
months). Regeneration occurs on every revocation and on a daily schedule.
The delegated responder answers SHA-1 and SHA-256 CertIDs for all issuing CAs, echoes request nonces per RFC 8954, embeds its responder certificate, and signs with ECDSA-SHA256. Responses are valid 24 hours. Serials never issued return unknown; requests for foreign CAs return unauthorized. OCSP is provided best-effort from a single instance — relying parties requiring high-availability revocation checking should prefer CRLs.
The CA performs continuous self-verification: an automated test suite exercises issuance rules, profile constraints, CRL invariants, OCSP semantics, and SSH certificate encoding against independent implementations (OpenSSL, OpenSSH) on every change. No independent third-party audit is performed. Relying parties requiring audited assurance should not rely on this CA.
Fees. None; issuance is at the Operator's discretion.
Warranties and liability. Certificates and timestamps are provided as is, without warranty of any kind. To the maximum extent permitted by law, the Operator disclaims all liability arising from use of or reliance on this PKI. A certificate binds a public key to asserted subject information; it does not warrant the conduct, products, or claims of any subject. A timestamp proves that the TSA attested to a hash at a time; it does not prove a document's contents are true.
Privacy. Issued certificates, their subject names, and revocation status are public. Audit logs are private to the Operator.
Governing law. The law of the jurisdiction in which ZDN Enterprises, LLC is organized, without regard to conflict-of-law rules.
Amendments. See §1.5. Prior versions are retained in the CA's version-control history.