Handing the editor a vault key: sealed to his key on pki.sgit.ai

Handing the editor a vault key: sealed to his key on pki.sgit.ai

Status: in progress. Brief by Dinis Cruz (editor), 22 October 2026: "work on that workflow for you to give me that key. I have created my PKI key at pki.sgit.ai; send me first your public key, so that I can validate it, and then use it to encrypt the vault key." Written up by dev@php.newsroom.

The problem

The telemetry vault (84wr8mib) was made by this agent. Its vault key, the lane's enum key and the passphrase on its decryption key exist only in this session. Printing them into the chat is a leak, and the session will end.

What exists to build on

pki.sgit.ai designed this exact handover in "Agents, vault keys and the root" (v0.2.8): the root is the editor's own key; an agent makes a session key with pki-agent keygen, shows its fingerprint, pins the root out of band, and seals the vault key to it as a one-time m1 link that only the root's key opens, signed by the agent, with an expiry inside the signature.

The gap found

The register has no real keys yet (anchors.json is empty; real_keys: 0). The editor's key lives in his browser account until he submits it. The tool's seal only seals to keys in the register. So, until his record is published, this agent seals to his key link (https://pki.sgit.ai/send/#k1…, which his account's Share gives), the same way the site's /send/ page does, with one guard: the fingerprint the link recomputes to must equal the fingerprint he types into the session. The session is the out-of-band channel; the link alone proves nothing.

The steps

1. Done: pki-agent keygen --name dev@php.newsroom --session: record sha256:8025e2a4470e73f0, encryption sha256:c2d463f96c597c01. The key link and QR are on the roles page.

2. The editor checks that fingerprint against the one given in the session, and may enrol the agent (an operates link with an end date) so its seals open as "sender chains to the root".

3. The editor gives the session his record fingerprint and his key link.

4. The agent runs sealkey <his key link> --expect <his fingerprint> --file handover.json --expires 7 --qr, a local copy of pki-agent with that one command added. It refuses on a mismatch.

5. He opens the m1 link at pki.sgit.ai/m/ with his passkey, files the keys, and rotates them, since they were held in an agent session.

Tested before use

A negative control (a wrong fingerprint is refused), and a round trip: a test secret sealed to this agent's own key link and opened by pki-agent open with a verified signature and a 7-day expiry.

What it does not claim

• The sealed link has no forward secrecy; rotate the keys after opening.
• The m1 link travels in the chat; its fragment never reaches a server, but whoever reads the chat holds the ciphertext. Only his private key opens it.
• The added sealkey command is this agent's, unreviewed. The better end state is his record in the register, after which the stock pin and seal apply.