# What pki.sgit.ai Is Missing: It Answers Whose Key This Is And Not What The Key May Do, And The Registry Is The Missing Half Of A Feature That Already Ships **version** v0.33.60 **date** 19 August 2026 **from** Human (project lead) **to** The sgit.ai site agent, Product **type** Cross-team brief *Fifth of 19 August. A review with recommended additions, written under a stated limitation: the site could not be read directly and this works from its own index entry. Contains one correction to a brief written earlier today, which was wrong on a cryptographic detail the site has since stated correctly.* --- ## What This Is Recommendations for the identity registry site, drawn from four briefs written since it was scoped, and one correction to source material rather than to a brief: **the site currently carries the argument it was scoped with, being the 2019 keyserver catastrophe, the four registry rules that failure produces, and a build order published before the registry exists so the commitments are checkable against whatever ships, and that is a good foundation which answers exactly one question, namely whose key this is; the largest gap is that it does not answer what a key may do, since two documents converged this week on identity and mandate being separate signed statements that are issued, revoked and reasoned about independently, and a registry recording only identity is half a system; the second gap is how a key gets in at all, because the bootstrap trap is the most linkable argument in the whole set and explains why agent key registries do not exist, and the transport that resolves it turns out to be shipped and account-less rather than theoretical; the framing that makes all of this concrete is available in the site's own documentation, since the PKI page states that the shipped feature has no revocation and no directory, which is precisely what a registry supplies, so the registry is the missing half of a feature that already exists rather than a new product, and that is a far stronger pitch than a general argument about key repositories; the authorisation model should be reused rather than invented, because the API already separates four capabilities with the server holding only hashes, which is the same discipline a registry needs; signed receipts complete a triangle the site is currently missing two corners of, since recording identity and delegation without recording exercise leaves the most auditable event unrecorded; two one-line principles belong on the site verbatim, one separating encryption from authorisation and one stating what a signature does and does not prove; and the site does not appear in search for its own name, which is the finding reported on 14 August, unresolved, and which prevented this review from reading the site at all.** It is the fifth document of 19 August (cross-ref: the v0.33.60 enrolment architecture, the v0.33.60 bootstrap trap, the v0.33.60 append lane correction, the v0.33.60 Service Twin brief, and the v0.33.59 PKI site brief). New contributions: **the mandate gap identified as the largest, the registry reframed as the missing half of a shipped feature, the capability model recommended for reuse, receipts as the third corner, and a correction to the source pack's cryptographic claim.** ## What I Could And Could Not See Stated first because it bounds everything below. **The site could not be read.** A direct fetch was refused by tooling that only permits URLs a search has already returned, and a search for the subdomain returned the package listing, the code repository and the main site, but **not the site itself**. A second attempt at a page linked from the main index was refused for the same reason. So this review works from the main site's index entry for it, which describes the content as the 2019 catastrophe, the four registry rules, and the build order published before the registry exists. **That limitation is itself the finding reported on 14 August**, unchanged: the documentation is excellent and unreachable to an agent under a common restriction. It has now blocked a review of a sibling site, which is a more concrete demonstration of the cost than the original report could offer. ## A Correction To The Source Material, Not To The Brief Recorded before the recommendations, because it is a specific claim that would get copied into an implementation. **The audit pack converted this morning describes the client sealing a payload to a recipient's X25519 key.** That is wrong. **The site now states it plainly and correctly**: keypair generation produces two pairs, **RSA-OAEP 4096 for encryption and ECDSA P-256 for signing**, and the documentation says explicitly that these are **not** X25519 or Ed25519. The envelope wraps an AES-256-GCM content key with RSA-OAEP. The brief converted from that pack does not repeat the error, because it described the sealing layer without naming a curve, but **anybody reading the source pack would inherit it**, and that pack is presumably still circulating. Worth correcting at source. **The boundary that brief drew does hold**, and the site states it the same way: the lane address derivation is **proposed**, no shipped command emits it, and today the token is agreed out of band. The site's own instruction is the right one and worth quoting anywhere this is described: do not code against the derivation. ## What The Site Has, And What It Answers The current content is a good foundation and it answers exactly one question. | Question | Answered? | |---|---| | **Whose key is this?** | Yes: the registry, its rules, the failure that produced them | | What may this key do? | **No** | | How does a key get into the registry? | **No** | | What happened when it was exercised? | **No** | The first is the hardest to get right and the site gets it right, including publishing the rules before the registry exists so they can be checked against what ships. That discipline should be preserved in everything added. ## The Largest Gap: Mandate **A registry that records identity and not delegation is half a system.** Two documents converged on this independently this week. The enrolment architecture keeps identity and mandate as separate signed statements. The execution broker document makes the mandate its **central authorisation object** and states the reason bluntly: a valid certificate proves a request came from a given agent, and proves nothing about whether that agent may perform the action. The distinction to publish: | Statement | Says | Revoked when | |---|---|---| | **Identity** | This key is this agent | The key is compromised | | **Mandate** | This agent may do these things, until this date, on whose authority | The permission changes | Two properties make the separation worth its cost, and both belong on the site because they are what distinguishes this from a bearer token. **They revoke independently.** An agent whose permissions change does not need a new identity; an agent whose key is compromised does not lose the record of what it was permitted to do. **And a mandate is checkable by a third party.** A bearer token tells a recipient only that the holder has it. A signed mandate tells them what was granted, by whom, and until when, without asking the issuer. The limit should travel with it, as it does in both source documents: **a mandate constrains what an agent may be authorised to do, not what it does within that authority.** ## The Second Gap: How A Key Gets In The registry is where keys end up. **The site does not explain how one arrives**, and the argument for that is the most linkable thing in the entire set. The bootstrap trap is a loop rather than a missing feature: an unknown agent must reach a trusted authority, every route requires authentication, and authentication requires an identity the agent does not have. Every common escape hands over authority broader than the identity being created, which is why the workarounds are the mechanism behind documented incidents rather than a theoretical concern. **Two things make this worth publishing now rather than later.** It explains the state of the field. The main network page already argues that for rented agents the honest answer is to hand over a broad credential and hope. **The bootstrap trap is why**, and the two arguments are considerably stronger adjacent than apart. And the resolution is shipped. The narrow account-less ingress that breaks the loop exists: a write to an append lane requires a token in the body, **no account and no access token**, and returns a blind acknowledgement. The site's own quick answers now say so. **So the enrolment path is buildable rather than proposed**, and the site can describe it as a working transport with a proposed convenience layer on top, which is exactly the shipped-versus-proposed discipline it already applies elsewhere. ## The Framing That Makes This Concrete The strongest available pitch is in the site's own documentation and is not currently being used. The PKI page states that the shipped feature provides keypairs, signing, encryption to a fingerprint and a contacts list, and that it has **no revocation and no directory**. **Those two absences are precisely what a registry supplies.** So the registry is not a new product argued for from first principles. **It is the missing half of a feature that already ships**, and stating it that way does three things a general argument cannot. It gives the site a concrete user: somebody already using the PKI commands who has hit exactly these two walls. It bounds the scope. A directory and revocation are a much smaller thing to build and to explain than a general public key infrastructure. And it makes the keyserver history land harder rather than softer, because the failure explains **why** those two absences are hard rather than oversights: the last system that tried both was destroyed by how it did them. ## Reuse The Capability Model, Do Not Invent One The registry needs an authorisation model, and one already exists in the platform with the right shape. The API separates four capabilities, with the server holding only hashes: a token that writes to one lane, a key that lists and fetches, a key that configures and purges, and a private key that decrypts and is never sent. **That is the discipline a registry needs**, and reusing it has three advantages over designing another. It is implemented and code-verified. The server-holds-hashes property is the catastrophic failure principle in practice, which the registry rules already invoke. And a second authorisation model in the same platform is a second thing to reason about, get wrong and document. The mapping is close to direct: who may append a statement to a record, who may read the record, who may configure it, and who holds the key that signs. The registry's own first rule, that only the owner writes to their own record, is a constraint on the first of those. ## Receipts Are The Third Corner Currently missing, and the execution broker document supplies it. Recording **who a key belongs to** and **what it was permitted to do** leaves out the most auditable event of all: **what it actually did.** A signed receipt establishes that a named party executed a named action for a named agent under a named mandate at a given time. The line from that document worth using directly is that this creates an evidence chain rather than relying solely on mutable platform audit logs. So the triangle is: ``` IDENTITY this key is this agent registry MANDATE this agent may do this registry RECEIPT this agent did this, under that evidence ``` The site does not need to own the third, and it should **name** it, because a reader arriving at a key registry is usually trying to answer a question about something that happened, and the registry alone cannot answer it. The three-question layering from that document is the clearest statement of how these fit and belongs on the site nearly verbatim: identity asks who this agent is, the mandate asks what has been delegated, and the execution layer asks whether that delegation should produce this effect now. ## Two Principles To Publish Verbatim Both are one-liners, both are precise, and both prevent a confusion a key registry exists to prevent. **On encryption and authorisation**, from the execution broker document: > Encryption restricts who can read a mandate. The signature and subject binding establish who may exercise it. That matters because the two are conflated constantly, and conflating them produces somebody believing a mandate is safe because it is encrypted, when what makes it safe is that exercising it requires a private key the reader does not hold. **On what a signature proves**, from the enrolment architecture: > A signature over an enrolment request proves the submitter controls the corresponding private key. It does not prove that the project should trust the agent. Trust is a policy decision made afterwards. Both are the sort of statement that stops a reader building the wrong thing, which is what a documentation site is for. ## One Thing Still Open Fractal registries recognising other registries appears in the scoping brief and in the enrolment architecture, and neither resolves it. **A fractal trust structure requires roots.** Each registry must declare which roots it accepts, or a chain cannot be evaluated by anybody trying to verify it. Who may be a root is a privileged decision and needs a stated answer even if the answer is that an operator sets it once. Worth putting on the site as an open question rather than omitting it, since the site's established practice is to publish what is not yet settled. ## Recommended Additions, In Order 1. **The mandate page.** Identity against mandate, independent revocation, third-party checkability, and the limit. This is the largest gap. 2. **The bootstrap trap page.** Why registries for agents do not exist, and the account-less lane that breaks the loop. The most linkable argument available. 3. **Reframe the registry as the missing half of the shipped feature**, citing no revocation and no directory. This changes the pitch from general to concrete and is a paragraph rather than a page. 4. **The capability model**, reused rather than invented, referencing the API pages. 5. **Receipts named as the third corner**, with the three-question layering. 6. **The two principles**, verbatim. 7. **The open question on trust roots.** ## What This Does Not Recommend - **Not building the registry first.** The site's practice of publishing commitments before the thing exists is right and should continue. - **Not a second authorisation model.** Reuse the four capabilities already implemented. - **Not owning the execution layer.** Name receipts; the broker is a different product line. - **Not restating the keyserver history.** It is there and it is good; the additions sit around it. - **Not asserting the derivation works.** It is proposed, no command emits it, and the site already says so. --- ## Key Points | # | Point | |---|-------| | 1 | The site could not be read directly, which is the 14 August discoverability finding, unresolved | | 2 | The source audit pack names X25519; the shipped PKI is RSA-OAEP 4096 and ECDSA P-256, and the site now says so | | 3 | The site answers whose key this is, and not what the key may do | | 4 | Identity and mandate are separate signed statements that revoke independently | | 5 | A mandate is checkable by a third party, which a bearer token is not | | 6 | The bootstrap trap explains why agent key registries do not exist, and is the most linkable argument available | | 7 | The account-less append lane that breaks the loop is shipped, so the enrolment path is buildable | | 8 | The shipped PKI has no revocation and no directory, which is exactly what a registry supplies | | 9 | That reframes the registry as the missing half of an existing feature rather than a new product | | 10 | The four-capability model with hash-only server storage should be reused rather than redesigned | | 11 | Receipts are the third corner: identity, mandate, and what was actually done | | 12 | Fractal registries need declared trust roots, which remains open and should be published as open | --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).