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 key set is published at https://api.purposesource.org/jwks.json, and the apex https://purposesource.org/jwks.json is a route onto that same edge Worker. This site publishes its own second copy at https://purposesource.org/artifacts/jwks.json. Each copy carries its own build metadata, so compare the keys and not the whole document — the recipe is on the verification procedure. The set 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 two copies are written by two separate deployments — the Pages build for this site’s, the Worker bundle for the edge’s — so a reader who distrusts one can diff them, and a key substituted in one deployment cannot forge trust. Both are built from the same committed file: the diff proves the two deployments agree, not that the copies were sourced independently. The copy that would prove that, committed with signed commits to a public repository, is not yet published: it publishes when the mirror repository and its signer are named. Until then the check is between two copies, not three, and this page says so rather than counting one it does not have.

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 Azure Key Vault (Standard tier, software-protected, Switzerland North) and non-exportable: the private key cannot be exported in readable form. It exists only inside Key Vault, and in any encrypted Key Vault backup, which can be restored only into a Key Vault in the same Azure subscription and geography. Nobody, us included, holds a readable copy of it. Signing is an operation the vault performs; our services send it only a digest to sign.
• Created by one person, not in a two-person ceremony. The operator created this key in the vault by hand on 2026-09-02, alone: there was no second person yet to take part. Our runbook requires every later key (the January rotation, and any emergency rotation) to be created in a two-person ceremony: the operator and a second admin on a recorded session, each checking the public-key thumbprint independently, with the ceremony record (key id, date, roles present, vault object version, public JWK) published with the key set.
• One person can make it sign today. Until our signing service takes over in production, the operator’s own account holds a standing permission to make the vault sign. It ends on 2027-06-30 at the latest, and is removed when the service takes over. There is no second person yet, so no two-person control applies to signing today. Every certificate is still logged in the append-only transparency log before delivery.

The key’s public JWK is published. /jwks.json lists psn-prod-2026-1 as active, with its validity window and its public coordinates — the same coordinates the key vault reports for the key object, so anyone can compare the two. Its RFC 7638 thumbprint is CiSAu8oPn-4kV6JU4HZQCdvcnS0G6mN7oUPjdyJ2_Wo, and it is recomputable from the coordinates in the key set.

The ceremony record — not yet published. The two-person ceremony and its record are still owed, and remain a precondition of the first certificate. They cannot change how psn-prod-2026-1 was created, and the record will say so. Publishing a public JWK is a key-set act and not a ceremony act: the coordinates above were read from the recorded vault key object, so their presence here is not the ceremony record and should not be read as one. Nothing on this site carries that record until it exists.

Publication of the key is likewise a precondition of the first certificate, not evidence of one: no certificate has been issued, and the verification page says exactly that. What a published key set buys you today is that the signature check is already verifiable — you can resolve a kid, read the coordinates, and confirm this page and the machine endpoint agree, before anything depends on the answer.

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, check that the token’s signing time falls inside that key’s validity window, 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.