Are we self-sovereign PKI yet? · Buffrr

Signal is end-to-end encrypted in the sense that the keys are end-to-end. Whether you got the right keys is a different question, and almost nobody asks it.

Safety numbers on Signal exist because, in principle, the server could hand you the wrong key for your contact. You’re supposed to walk through one the first time you talk to someone you care about. In practice, almost nobody does.

iMessage shipped the same idea in late 2023, called Contact Key Verification:

WhatsApp has a Security Code. Threema rates contacts red, orange, or green depending on how they were added. Matrix has cross-signed device verification with comparison emoji. PGP has fingerprints, which is where this whole pattern started, and about which there is little left to say beyond Filippo Valsorda’s 2016 essay.

Signal ships safety numbers because the platform might one day be compelled or compromised, and the architecture is meant to let you catch that. But almost nobody verifies. So the encryption ends up end-to-end conditional on the platform being honest, even though the design tried to be conditional on something stronger. Almost word for word the property you wanted to avoid by encrypting in the first place.

The shape of the problem

It is not just messaging. The same gap shows up wherever you need to bind a public name to a key.

You can publish an email address. Email is rented from a provider that can read it, suspend it, hand it over, or refuse to deliver mail from it. In April 2026, Google handed a user’s account data to ICE without notifying him in time to challenge the subpoena, breaking a decade-old promise. Self-hosting is not really an escape: since November 2025, Gmail has been rejecting messages from senders that don’t pass DMARC alignment at the SMTP level rather than filtering them. Running your own mail server now means convincing the majority providers your domain looks legitimate. Email-as-an-ID was never quite a standard; it was a custodial relationship.

You can publish a username. Twitter, GitHub, Bluesky, ProtonMail, Telegram, Discord, your registrar. Each of them owns a slice of your name, and there is no way to prove the slices belong to the same person without trusting yet another platform. Keybase noticed this over a decade ago and built cross-platform identity proofs: signed claims posted on each of your accounts, all linked to a single key. The bottom of the stack was still a key fingerprint, with the same problem Signal has now. But it did solve a smaller and real problem: tying scattered identities together, so the @_buffrr on Twitter and the @buffrr on GitHub could be checked against the same key. Zoom acquired Keybase in 2020. Public hosting was killed in 2023, and the rest has been left to rot.

You can publish a key fingerprint, if you have already given up.

Why the existing PKI doesn’t fix this

We have public-key infrastructure for machines. We don’t have it for people. And the PKI we have for machines is a tower of custody.

CAs validate domain ownership by looking up DNS records. Until March 15 of this year, CAs were not required to validate DNSSEC at all when doing so, and even now they are only required to validate DNSSEC when it is present, which is on a small minority of domains. A BGP route leak or a registrar compromise that diverts your domain’s DNS for ten minutes can therefore still produce a real, browser-trusted certificate for your domain. This is not theoretical; it has been used in the wild. The CA/Browser Forum’s response, Multi-Perspective Issuance Corroboration, checks from several network vantage points to make BGP attacks harder. It is also a workaround.

DANE was the standards-track answer to all of this. It didn’t ship in browsers. DNSSEC itself is not really a self-sovereign trust root either; ICANN holds the keys.

Certificate Transparency is sometimes invoked as the success story. CT solves a different problem: detecting misissuance after the fact, against append-only logs operated by what’s currently about six organizations. Trusting CT comes down to trusting that those operators won’t all collude. That’s hard, but it isn’t self-sovereign. And CT isn’t the bottom of the stack. DNS is, and CAs use DNS to decide who gets a certificate.

Email PKI follows the same pattern. S/MIME routes through a corporate CA. WKD routes through the email provider, which is the party you were trying to encrypt past.

Every layer is custodial. Every layer assumes you trust someone.

What would actually help

A name like grace@key that resolves to a public key. The same key, in every app, for every recipient. Not assignable to anyone else, not revocable, not subject to suspension. Yours forever. No fingerprint to verify out of band, because resolving the name is verifying the binding to a key.

Not a better platform. Not a more auditable CA. No privileged operator at all.

This works today:

$ cargo install --git...