Home / Articles / A directory of people and their keys: pki.sgit.ai for the people I work with, verified by me first, then by each other, and a link that only counts when it goes both ways

A directory of people and their keys: pki.sgit.ai for the people I work with, verified by me first, then by each other, and a link that only counts when it goes both ways

By Dinis Cruz · 2026-10-18 · article v1.0.0 · newsroom v0.12.114 · pkipublic-keysidentityweb-of-trustpasskeyssgitbriefarticle

Abstract: One of the first things I wanted when I started building these tools was a place to publish people's public keys, so I could find someone and send them something only they can read. I got stuck because there was nowhere good to put them. Now sgit is moving to public-key cryptography, and we have the pieces to build it, so it is time. The brief is for the agent that runs pki.sgit.ai, which until now has designed a key registry for agents. The first records should be people. You go to the site, register a passkey, and it opens a vault, as the newsroom's does; you make a key pair, or bring one, and publish the public half. Then you add evidence: your website, GitHub, a DNS record on a domain you own. For now I am the anchor: I verify people, by meeting them or on a channel I already know is theirs, and sign it, and they confirm it. Then anyone verified can verify someone else, and one rule makes it safe: a link only counts when it goes both ways. I can say I know you; you still have to say you know me. That rule, written in each person's own record, is also the answer to how the old web of trust was destroyed in 2019. From the links come degrees of separation, and an invitation is a QR code. The point is practical: find someone, and send them a secret or a message, as a QR code that opens in their browser. The number to watch is how many real keys are in the register.

In short

• A place for the keys of the people I work with. So I can find someone and write to them securely.
• Start with the key. A passkey opens a vault; the vault holds the private keys; the public half is published.
• Evidence, then verification. A website, GitHub, a DNS record; and for now, me as the anchor.
• A link only counts when it goes both ways. Which is also the answer to how the old web of trust was destroyed.
• Degrees of separation, and invitations by QR code. So it can spread from person to person.
• The use is practical. Send a secret or a message that only that person can read.
• One number for now. Real public keys in the register.

Why now

This is one of the first things I wanted when I started building the first of these tools. I wanted to send someone a file or a secret encrypted to them, and I needed their public key, and there was nowhere good to find it. So I got stuck, and built other things.

Now the pieces exist. sgit is moving to public-key cryptography: secrets on public keys said we would stop sharing keys altogether and give every person, browser and agent a key pair. sgit already makes the keys: an encryption pair and a signing pair, exported as a small bundle. And its own documentation lists what is missing, in one line: "No web of trust and no directory" (sgit.ai/docs/pki.md). This is that directory, so it completes something that ships rather than starting something new. I think it is a big milestone, and it has an interesting viral side.

Is there really nowhere?

I said in the memo that there is no good place to publish public keys. The research says that is too strong, and the difference matters. There are places. GitHub serves anyone's public SSH and GPG keys at a simple address. keys.openpgp.org publishes keys after checking an email address. Keybase, bought by Zoom in 2020, still runs, but without new features. Keyoxide links a key to your accounts with proofs both ways, and has been quiet since 2023.

What there is not is a web of trust that works. The old keyserver network allowed anyone to add a signature to anyone's key, and nothing could ever be deleted. In June 2019 attackers flooded certain people's keys with signatures until importing them broke the software, and the network could not be repaired; its public pool shut down in 2021. Its replacement, keys.openpgp.org, simply refuses third-party signatures "due to spam and potential for abuse". pki.sgit.ai already tells that history in detail, and asks the question it leaves: if you allow people to vouch for each other, how do you stop it being abused?

So what is missing is the combination: keys made and held in the browser, evidence of several kinds, someone to start the trust from, vouching that cannot be abused, and a way to actually send something to the person you found. Nothing I could find does all of that.

Start with the key

The workflow starts on pki.sgit.ai. You register a passkey, and it opens a vault, exactly the way the reader's vault on this newsroom does, as a pane on the side or a full page. In the vault you make a key pair, or import the one sgit already made for you. The private keys never leave it. The public half is published as your record in the register, signed with your own key.

That order matters. Nobody gets a record from someone else's description of them. I can keep a list of people I want to invite, from LinkedIn or anywhere else, but in my own vault; the register only ever holds people who made their own key and published it themselves.

Evidence

Then you add evidence that the key is yours, each piece a signed claim in your own record:

• A website you control, with your key's fingerprint at a known address.
• GitHub, with the fingerprint in a public profile or gist; GitHub already publishes users' SSH keys.
• A DNS record on a domain you own, the pattern Bluesky uses for its domain handles.
• Keys you already publish elsewhere.
• LinkedIn and other profiles, as links a person checks.

You can do it from a form on the page, which writes to an append lane, so you need no account, or from your vault.

I am the anchor, for now

Evidence says an account and a key go together. It does not say the person is who they say. So for now I am the trusted element: I verify people. I know many of them already. I meet them, or check through a channel I already know is theirs, a call or a message, and I sign a statement: this key belongs to this person, verified on this date, by this method. The details stay in my vault; the method and the date are public. And the person confirms it from their side, which is the second factor.

Being the anchor is a choice, and I would rather state it than hide it. It is how this starts, not how it has to stay.

Two ways, or not at all

Then the part that makes it spread: anyone who is verified can verify someone else. And one rule, which I care about a lot: a link always goes both ways. If I say I know you, that is my claim. You still have to say you know me. I can always say I vouch for someone; they might say they have never heard of me.

It turns out that rule also answers the question the old web of trust left open. pki.sgit.ai's first rule is that only the owner writes to their own record. So my vouch for you is written in my record, and your confirmation in yours. Nobody can add anything to anybody else's record, which is exactly what the 2019 attack did. A vouch nobody confirmed is visible as a claim in the voucher's record, and adds nothing to the other person. A link exists only when both statements do. And each record has a limit on how many it can hold, so even your own record cannot be turned into a flood.

Degrees of separation

From the confirmed links, the site works out the graph: who is verified, by whom, and how many steps anyone is from me, or from anyone else. That is interesting in itself. If I am two steps from someone, I can see through whom, and I can ask to link directly; they still have to approve. The degrees are computed from the records each time, never stored as a fact.

Invitations by QR code

To grow it, I invite people, and they invite theirs. The invitation is a QR code with the URL printed above it, which has worked very well for me in person. You scan it, register a passkey, make your key, and the first link, to whoever invited you, is waiting for you to confirm.

What it is for

• Find someone and write to them. The register becomes where I go to find people and send them messages.
• Send a secret by QR code. A page where I write a message, it is encrypted in my browser to your public key, and I give you a QR code. You open it in your browser, your vault reads it, and nothing readable passes through a server. We built pieces of this a long time ago, sending messages to a browser; now there is a key to send them to.
• Hand out access. There are people I want to give an SG/Send token, or the keys to vaults I create for them. Encrypted to their key, not pasted into a chat. This is what handing secrets to agents needs, for people.
• Sign opinions. On the record needs exactly these keys, and this verification, for experts to sign what they say about an article.

The brief

The build brief is a note for the pki.sgit.ai agent: a directory of people and their keys. It briefs the agent on where everything is now, the newsroom, sgit and RiskMandate, before the work; it checks the prior art; and it sets the order: people first on the site; the passkey and vault, reused from the newsroom; keys made in the browser and compatible with sgit's; evidence; my verification; two-way links and the graph; sending by QR code; invitations. It is also on the briefs page. I already have a list of people I want to bring on board.

What this does not claim

• Nothing new is built. pki.sgit.ai has a register with one real record and ten test ones; this is the brief to fill it.
• There are places to publish keys. What is missing is the combination, as of 18 October 2026.
• Two-way links stop flooding, not lying. Two people can confirm each other falsely; the anchor and the evidence are what make a link worth something.
• I am a single point of trust, at first. Stated on purpose.
• Passkey support varies. The vault depends on a passkey feature that some browsers and password managers handle unevenly.

If you want to be one of the first keys in the register, write to agent@riskmandate.ai.

Where this comes from

A voice memo from me on 18 October 2026. pki.sgit.ai, its llms.txt, failure page and rules, read that day; sgit's keys documentation and vault messaging. The research, read by a research agent: keys.openpgp.org; Keyoxide's documentation; TechCrunch on Zoom buying Keybase and an April 2026 essay on Keybase today; Latacora, The PGP problem; the AT Protocol's handle specification; RFC 7929. Related: secrets on public keys, handing secrets to agents, on the record, the vault, opened, the man behind the curtain. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles