Keys and the transparency log

The one place to verify

verify only at purposesource.org/verify

That wording is fixed. Any page, PDF, badge, or email that offers a different verification address is not ours, whatever it looks like. Machine endpoints exist and are documented in the API reference, but the human verification page is the canonical statement, and no other host is ever printed as one.

The key set (JWKS)

Certificates, entitlement records, vesting snapshots, and transparency-log checkpoints are ES256 tokens (ECDSA over P-256 with SHA-256), in compact JWS form. The public key set is published at two URLs that serve the same document: https://purposesource.org/jwks.json and https://api.purposesource.org/jwks.json. It carries every key ever used — current and retired — with a status and a validity window on each entry, so a certificate signed under a retired key still verifies.

The same key set is committed, with signed commits, to the public specification repository at https://github.com/purposesource/spec. A reader who distrusts this site can compare the two; substituting a key on the website alone cannot forge trust.

The production key: psn-prod-2026-1

Key ids follow psn-{env}-{yyyy}-{n}. The production signing key is psn-prod-2026-1:

• ES256, EC P-256, sign-only.
• Born inside an HSM-backed key vault (Azure Key Vault, Switzerland North) and non-exportable: no copy of the private key exists anywhere, including with us. Signing is an operation the vault performs; the key never leaves it.
• Created in a two-person ceremony — the operator and a second board-designated principal, on a recorded session, each verifying the public-key thumbprint independently. The ceremony record (key id, date, roles present, vault object version, public JWK) is published with the key set.
• No human holds standing permission to sign. At v0 the operator-run signing tool obtains a time-boxed, logged permission for each signing session; the two-human control is the pull-request review that appends the log entry.

The key’s public JWK appears in /jwks.json on completion of the ceremony, which is a precondition of the first certificate. A key set that does not yet list it is the honest pre-ceremony state, not an outage, and the verification page says so.

Rotation policy

• Scheduled: annually, each January, aligning the year in the key id (psn-prod-2027-1 follows psn-prod-2026-1).
• Overlap: a new key is published in the key set at least seven days before its first use, so relying parties’ caches are warm; issuance cuts over in a single configuration change.
• Never removed: retired keys stay in the key set indefinitely with their validity window. Rotation never invalidates an old certificate.
• Compromise: rotation plus reissue, never key restore. A declared compromise window is annotated on the key entry itself; the log is re-verified against issuance records for the window; hashes with no matching record are published as forged; genuine certificates from the window are reissued with supersede links.

The transparency log

Every production certificate’s SHA-256 — of the compact JWS, not of the PDF — is appended to an append-only log before the certificate is delivered. A certificate absent from the log renders UNVERIFIED — not in the transparency log on the verification page even when its signature is perfect. That is the property the log exists for: it makes a validly-signed but unrecorded certificate detectable.

Browse the log. The current segment is served at https://api.purposesource.org/ct/latest.json and numbered segments at https://api.purposesource.org/ct/{n}.json; the same files are committed to the ct/ tree of the public website repository, appended by pull request, with a continuous-integration guard that rejects any diff editing or deleting an existing entry. Monthly checkpoints — a signed git tag plus a checkpoint token signed with the production key — commit the log head.

Log entries contain a hash, a type code, and a timestamp. No names, no email addresses, nothing personal; the log is safe to mirror forever.

Sandbox keys are a disjoint set at a separate path, and sandbox-signed tokens never enter the log. A sandbox-signed certificate can never render as a production credential — the verification page banners it as a test artifact before it says anything else about it.

Verify offline

The verification page checks a signature in your browser, with no server in the trust path. To verify without this site at all: resolve the kid in a copy of the key set, verify the ES256 signature over the compact JWS, then check that the SHA-256 of the compact JWS appears in a log segment. Step-by-step instructions, with WebCrypto and OpenSSL, are in Verify a certificate offline.