The cryptography proves consistency, not third-party time

The verifier at /certificates/verify is real and it works. It recomputes the SHA-256 of each canonicalized certificate, rebuilds the Merkle tree, checks every inclusion proof against the published root, and verifies the ECDSA P-256 signature over that root using the public key at /.well-known/rhio-cert-pubkey.json, in your browser, with WebCrypto. None of that is theater. You can read the source and run the math yourself.

Here is the honest boundary. The signing key is self-held and local. The signer attests its own certificates. That means the registry proves internal consistency and tamper-evidence relative to one published key: if a stored certificate were altered after signing, a proof would break and you would catch it. It does not prove independent time. There is no third-party timestamp authority in the chain yet. The registry says so in plain text, the OpenTimestamps Bitcoin anchor is “planned,” not shipped. So a sufficiently motivated operator (me) could regenerate the key and re-sign a rewritten history, and an outside party could not, from cryptography alone, prove which version came first. The git history and the published key are the only things pinning the timeline, and both sit under the same roof.

Severity is medium, not high, because the language on the site is already careful. It says “signed Merkle root, published public key, append-only git history” and labels the anchor as planned. Tamper-evidence against a published key is a real property most personal sites do not have. But a buyer who governs agents for a living will ask exactly this question, and the site should answer it before they do.

The fix: ship the OpenTimestamps anchor so the Merkle root is stamped into Bitcoin and the timeline stops depending on my good behavior. Publish the key fingerprint somewhere off this origin, a DNS TXT record or a public bio, so the key cannot be silently swapped. Until then, keep the wording exactly as honest as it is now.