# The Register Was Designed In June: What Is Left Is Operationalising It, And The Published Keypairs Are Fixtures Rather Than Identities

**version** v0.33.61
**date** 20 August 2026
**from** Human (project lead)
**to** Engineering, Architecture, Security, the pki.sgit.ai site agent

**type** Architecture brief

*First of 20 August, and the first of two from one memo at the project lead's request. The prior registry design was located in the repository and is quoted from it rather than recalled. The agent card format, the signing mechanism and the platform's secret controls are checked and cited. The estate's own documentation site and the key registry site were fetched directly, so the pages on public key infrastructure, vault messaging and honest limitations are quoted from rather than inferred. Limitation: the repository clone available today ends at 14 August, so the 16 and 19 August briefs are known through the day index and the handoff pack rather than read in full, and their filenames are taken from those sources.*

---

## What This Is

The register the memo asks for, placed against the one this corpus already specified, and the correction that the published keypairs are not identities: **the memo proposes a public key register holding identities and evidence, plus a class of agent personas published with both halves of a keypair so that a new session can bootstrap a librarian or a cartographer by fetching a role definition and a key, and the first thing to record is that the register itself was designed on 5 June in detail, with clues rather than storage, public keys carrying metadata and relationships, two levels of trust in which downward trust is asserted by the truster and upward trust is self-declared by the subject and grants nothing, the register as a vault holding no private data, the register as a graph, connectors to any identity provider, and resolution as the caller's responsibility, so what is being asked for today is operationalising that design rather than producing one, and the memo's own instinct that a document exists is correct; the correction that matters is that a keypair whose private half is published is not an identity and cannot become one, because a signature it produces proves nothing about who produced it and a message sealed to it is readable by everybody, which means these objects belong to a separate class, best named a fixture, whose whole purpose is to exercise the plumbing and which must never be reachable from the trust graph that real keys inhabit; the June brief's own rule that the register never contains private keys should be kept rather than relaxed, so the register holds the public half plus a flag recording that the private half is published, and that flag is the single most important piece of evidence any entry can carry; the memo's proposed proof, that a key is trustworthy because it came from the trusted website, is a domain attestation, which the June connector model already generalises and which is the weakest signal in that model rather than a new one, and the 2019 keyserver failure supplies the rule that governs how evidence is written, since evidence about a key must be appended by the party asserting it to its own record and never to the subject's; three external facts change the plan rather than decorating it, because the persona format the memo describes already exists as a published agent card served from a well-known path, its specification states plainly that a card should not carry credentials, the signing hypothesis using platform actions is already implemented by a project that signs those cards with a workflow identity and records the signature in a transparency log, and the platform's own secret scanning blocks private keys on push by default, which means the plan as stated will be stopped by a control that exists for the right reason and that publishing the keys inside vault ciphertext evades that control rather than satisfying it; the registry site has already published four rules derived from that same failure, before it holds a single entry, and a fixture tests them immediately by satisfying two and voiding two, which settles how a fixture is retired since it cannot be revoked through a mechanism whose signing key is public; and the bootstrap workflow does not answer the persistence question left open on 19 August, because it replaces persistence with retrieval and retrieval only works while the key is public.** It is the first document of 20 August (cross-ref: the v0.32.4 registry brief, the v0.32.3 trust and identity brief, the v0.33.60 append lane brief, the v0.33.60 bootstrap trap brief, and the v0.33.60 pki site review). New contributions: **the prior design located and restated so it is not redesigned, the fixture class named and bounded, the private key flag as evidence, the keyserver rule applied to evidence authorship, the agent card identified as the persona format, the signing hypothesis found already built, the fixture tested against the registry site's four published rules, and the secret scanning consequence stated in both halves.**

## This Was Designed On 5 June

The memo suspects this and the suspicion is right. The project lead: **"In fact, I think we already wrote a document about this a while back about it."**

It is `v0.32.4__dev-brief__sg-send-pki-public-key-registry-on-vaults.md`, and it is not a sketch. It settles seven things that today's work should inherit rather than re-derive.

| Settled on 5 June | What it means for today |
|---|---|
| Clues, not storage | The register points at information rather than holding it |
| Public keys, metadata and above all relationships | An entry is a node; the edges are the value |
| Two levels of trust | Downward is asserted by the truster, upward is self-declared by the subject |
| Self-declaration grants nothing | A key saying it should be trusted is a request that the named party confirms or denies |
| The register is a vault | Public keys, hashes, mappings, and payloads encrypted to keys it does not hold |
| Connectors to any identity provider | A DNS record, a code host account, an authorisation provider, all uniform |
| Resolution is the caller's job | A resolver walks the graph, handles cycles, and may return a partial result |

Two of those are load-bearing for the memo's actual question. **Explicit distrust is a valid signal**, not an absence, which is what makes the evidence model richer than a trusted or untrusted bit. And **a partial resolution is a legitimate output**: I followed the chain this far, gained this much trust, and stopped because I lack the keys to continue. Both were written in June and both are exactly what an evidence model needs.

So the ask today is narrower than it sounds. The design exists, the vault primitive exists, the site exists, and what is missing is a first population of entries and the workflow that puts them there.

## A Published Private Key Is Not An Identity

This is the correction the memo needs, and it is a correction of shape rather than of fact.

The memo is explicit that confidentiality is not the goal. The project lead: **"the point here is this is less for worrying about impersonation and malicious, but more about having an ecosystem that starts to work."** That is a reasonable objective and the conclusion drawn from it is too strong. A keypair with a published private half does not provide weak authentication. It provides none, and it never will, because:

| Property | With a private key held | With a private key published |
|---|---|---|
| A signature proves the signer | Yes, possession is proven | **No. Anybody can produce it** |
| A sealed message is confidential | Yes, to the holder | **No. Anybody can open it** |
| Revocation means something | It stops the holder | **Nothing. There is no holder** |
| The key can later be promoted | Yes | **No. It is spent permanently** |

That last row is the one that costs money later. **A published key cannot be upgraded into a real one.** If the librarian persona becomes a thing that actually signs artefacts people rely on, its key must be regenerated and every reference to the old fingerprint reissued.

So these objects need their own name and their own class. **A fixture** is the honest one: a working example whose value is that it runs, and which is structurally incapable of carrying trust. Naming it now is the same cheap move as the three naming collisions already caught in this corpus, and it is cheaper here because nothing has shipped.

## What The Fixture Class Is For, And Where It Stops

Bounded properly, the memo's proposal is good and worth doing this week.

**What it is for.** Exercising the choreography end to end: generate, publish, discover, fetch, sign, verify, seal, send, open. Every one of those steps has a shipped command or a shipped endpoint, and none of them has ever been run as one sequence by an agent that started from nothing. That sequence is the thing worth having, and running it with fixtures costs nothing if a fixture is compromised, because a fixture cannot be compromised.

**Where it stops.** Three boundaries, all structural rather than documented.

**One. A fixture is never reachable from the real trust graph.** No real key vouches for a fixture, and a fixture's self-declared upward links are recorded and never confirmed. Under the June model that is already the correct outcome: a self-declaration grants nothing until the named party confirms, so a fixture sits permanently in the pending state, which is precisely where it belongs.

**Two. A fixture's append lane is a public inbox.** This follows from the shipped surface and deserves stating because it is easy to miss. The lane is write-only and account-less, and the recipient decrypts client-side with the private key. If that private key is published, **anything sent to that lane is readable by anybody who fetches it.** So a fixture may receive demonstrations and must never receive anything real, and the page publishing it should say so in those words. Note also that the derivation of a lane address from a public key remains proposed rather than shipped, and the estate's own limitations page states that boundary precisely, under a heading recording what the public key infrastructure does not do yet: the intended model is that the append token is the hash of the public key, the server side ships, no shipped command emits that token, and so a token is agreed out of band today. For a fixture that is not a workaround but the natural case, because the whole object is public and the token can be published beside it.

**Three. A fixture is marked in the register itself**, not in prose beside it. See the next section.

## The Register Holds The Public Half And A Flag

The June brief drew this line and today's memo crosses it. Recorded plainly rather than quietly reconciled.

June: the register stores public keys, metadata, hashes and relationships, and **never private keys or secrets**, so that there is nothing in it worth stealing. Today: **"we have agents that we only put in the public key, and agents that we put the public and the private key both on the site."**

Both can be true, and the way to make them both true is to keep the register's rule intact and put the fixture material somewhere else:

```
   REGISTER (a vault, public content)
     entry: fingerprint, public key, metadata, relationships
     entry: private_key_published = true | false        <- required field
                  |
                  | points at
                  v
   FIXTURE MATERIAL (a separate, clearly named vault)
     the private half, the role definition, the worked examples
```

The required field is the point. **A boolean recording whether the private half is published is the most consequential piece of evidence an entry can carry**, because it determines whether any signature by that key means anything at all. It should be a first-class field with no default, so that an entry cannot be created without somebody answering the question, and every consumer of the register can filter on it before evaluating anything else.

This also gives the register a property worth having on its own: it can answer, in one query, which of its entries are decorative. Very few key registries can.

## Evidence Is The Vouching Model, And The Website Is Its Weakest Connector

The memo asks what evidence looks like. The June model already answers it, and the memo's own proposal slots into it as one case rather than as the mechanism.

The project lead: **"the sign or the evidence that you get here is the fact that it comes from the trusted website."**

That is a **domain attestation**: this key appeared at a location controlled by a party you already trust. It is real evidence and it is the weakest kind in the June connector model, which named DNS records, code host identities and authorisation providers as equivalent sources of identity properties. Its specific weakness is that it inherits everything from control of the domain, so the entire register's credibility is bounded by the site's deployment pipeline, and this site is served from a vault whose write key is a single string with no reset.

Which produces one requirement worth carrying into the build: **the escrow item already standing since 14 August is a precondition here rather than a good idea.** A register published from a vault whose write key is lost is frozen, and a frozen key register is worse than none, because it can never retract an entry.

## Evidence Is Appended To The Asserter's Record, Never The Subject's

The rule the pki site is built on, applied to the thing the memo is asking to build.

The 2019 keyserver failure is the corpus's standing example of append-only going wrong, and the qualifier already recorded is that append-only is safe when a writer appends to what it owns and fatal when anyone may append to another's record. A register of identities plus evidence is exactly the shape that failed: certificates carrying unbounded third-party attachments that the subject could neither remove nor refuse.

The key registry site has already published the rules that failure produces, and it published them before holding a single entry, which makes them commitments rather than intentions: only the owner writes to their own record, revocation is a signed append rather than a deletion, records are size-bounded, and every entry is signed by something a reader can check. The first of those is the rule below, in the estate's own words.

So the structural rule for evidence is:

| Who writes it | Where it lives | What the subject can do |
|---|---|---|
| A vouches for B | **In A's record** | Nothing, and nothing is needed |
| B claims A vouches for it | In B's record, as a self-declaration | It is B's own record |
| Anybody attaches evidence about B | **Not permitted in B's record** | The failure mode, prevented by construction |

The June model already has this shape, since downward trust lives in the truster's own dataset. Stating it as the rule rather than as an implementation detail is what makes the register resistant to flooding, and it is the commitment the pki site has already published, which means it is checkable against whatever ships.

## A Fixture Satisfies Those Rules In Letter And Voids Two Of Them

The four rules are the register's own published commitments, and the fixture programme is the cheapest test they will ever get. Two survive contact and two do not.

| Published rule | A fixture under it |
|---|---|
| Only the owner writes to their own record | **Holds, and is empty.** A fixture has no owner, since everybody holds its private half, so the rule permits everybody |
| Revocation is a signed append, not a deletion | **Void.** Anybody can sign a revocation for a fixture, and anybody can sign the append that reverses it |
| Records are size-bounded | **Holds, and matters more here.** A fixture's lane is the natural flooding target, being account-less with a published key |
| Every entry is signed by something you can check | **Holds in letter, void in substance.** The signature checks, and it proves nothing |

The second row settles a question this brief would otherwise have left open. **A fixture cannot be retired through the register's own revocation mechanism**, because that mechanism is a signed append and the signing key is public, so a revocation carries exactly as much authority as the entry it revokes and can be reversed by anybody who disagrees. Retirement therefore means republishing the persona under a fresh key and reissuing every reference to the old fingerprint, which is the same cost as promotion and for the same reason.

The fourth row is the strongest argument for the required field. **A consumer that verifies signatures and stops there will pass a fixture**, because the verification succeeds. Only the flag distinguishes a signature that proves possession from one that proves nothing, which is why it has to be read before the signature rather than after it.

## The Persona Format Exists, And Its Specification Says Not To Do This

The memo describes a discovery flow. The project lead: **"that agent should be able to go to this website and grab the definition, grab the role, grab some examples of how it works that we can put in, and also can grab the public and a private key."**

Everything up to the last clause is a published standard. An agent card is a JSON manifest served from a well-known path declaring an agent's identity, capabilities, skills, endpoint and authentication requirements, the protocol reached version 1.0 under a foundation with broad vendor support during 2026, and version 1.0 added signed cards using JSON Web Signature so a client can verify a card before trusting what it declares. The specification also names a curated registry as one of the legitimate ways cards are found, which is the thing the memo wants to build.

Two details are worth taking exactly rather than approximately. **The canonical path moved**, and a recent survey of published cards found roughly a quarter still sitting at the older path where a compliant client will not look, so the current path should be used and the old one should not be relied on. And the specification states that a card **should not include sensitive credentials**, which is the same correction this brief reaches from the trust side, arrived at independently by the people who wrote the format.

The recommendation follows: **publish the persona as an agent card, and publish the fixture keypair as a deliberately non-conforming, clearly marked companion object.** Using the standard format costs nothing, makes the personas consumable by tooling nobody here has to write, and the deviation is then visible as a deviation rather than being invisible inside a bespoke format.

## The Signing Hypothesis Is Already Implemented

The memo carries a plan. The project lead: **"we already have an hypothesis of how we can sign them using, you know, GitHub Actions, and eventually we can add a lambda function to do it."**

The hypothesis is sound and it is built. Keyless signing issues a short-lived certificate against a workflow's identity token, the certificate lives for minutes, the private key is discarded after use, and the event is recorded in a public transparency log, so verification asks whether a specific repository and workflow signed a specific artefact rather than whether somebody held a key. Artifact attestations built on that reached general availability in 2024 and the default posture for public repositories has been tightening through 2026. **There is also a project that applies exactly this to agent cards**, signing a card with a workflow identity such that verification reveals the repository and workflow that produced it.

Three consequences.

**The notary must be an agent you run.** This is the two-populations thesis from 16 August arriving as an implementation constraint rather than as an argument. A workflow can be attested because you control where it executes. The librarian running in somebody's rented chat session cannot be, which is why the workflow signs and the persona does not.

**It answers the revocation gap, partly.** The shipped public key infrastructure has no revocation and no directory, which the pki site review named as the missing half on 19 August and which the documentation now states in its own words: no revocation or rotation workflow, no certificate revocation list, no expiry, no revoke command, no web of trust and no directory. A signature whose certificate expired in ten minutes and whose issuance is in a transparency log does not need revoking, because it was never durable. That is a different answer from a revocation list and it is available now.

**And it makes the fixture story honest.** A card signed by a workflow carries a real, checkable claim, that this site published this persona, while the fixture keypair inside it carries none. The two claims sit side by side and a verifier can tell them apart. That is a much better demonstration than one that pretends the fixture key means something.

## The Platform Will Block This, And The Vault Path Evades The Control

An operational finding, since the memo puts this on a code host. The project lead: **"all based on GitHub again, actions and vaults."**

Secret scanning covers generic, SSH and PGP private keys among its non-partner patterns, push protection is on by default for public repositories, and a blocked push must be resolved by removing the material, marking it a false positive, or marking it deliberately pushed, with every bypass logged.

So **the plan as stated will be blocked**, and the fix is a recorded bypass decision. That is acceptable for a fixture and it is worth doing deliberately, because the audit trail of somebody choosing to publish a private key is itself part of the demonstration.

The half that must also be stated: **publishing the same key inside vault ciphertext is not compliance with that control, it is invisibility to it.** The co-existence pattern puts encrypted objects in a git repository, and encrypted objects match no pattern, so nothing fires. That is true of any secret ever committed to a vault in a tracked folder, not just this one, and it generalises past today's question. It is the cost side of the property the product sells, and a site that publishes a runbook for the day it leaked its own key is the right place to say so.

## What This Does Not Answer About Persistence

One standing item deserves a precise answer rather than an assumed one.

The memo's bootstrap flow is elegant. The project lead: **"the problem is if I don't put the key there, then I have the problem of where is the private key, and in this case, the idea is to bootstrap it."** So the design substitutes **retrieval for persistence**: the agent does not keep a key between sessions, it fetches one each time.

The open question carried from 19 August asks whether a rented agent can persist a key between sessions, on the grounds that if it cannot, a mandate cannot outlive one conversation. **Retrieval answers that only while the key is public.** A real key cannot be re-fetched from a public location, by definition, so the fixture programme demonstrates the shape of the answer without supplying it. The item stays open, and this brief narrows it usefully: the question is not whether an agent can store a key, it is whether an agent can retrieve one over a channel that authenticates it, which is the bootstrap trap in its original form.

## Skills Are Artefacts, Not Principals

The memo raises this and asks for a note. The project lead: **"maybe with skills we also add keys to it. But start with agents, maybe add a note that maybe skills can come next."**

The note is that the two cases are different in kind and should not share a mechanism.

**An agent is a principal.** It acts, it can be delegated to, it can hold a mandate, and it can be wrong. Signing it with its own key is identity.

**A skill is an artefact.** It has no interests and takes no actions; it is text that an agent executes. What you want to know about a skill is provenance: is this the skill that was published, unmodified, by the party claiming to have published it. **That is artifact attestation, which the signing mechanism above already provides**, and giving a skill a keypair would suggest it could be a party to something, which it cannot.

So skills get signed and do not get identities. That is a one-line rule and it will save a naming argument later.

## Build Order

1. **The fixture class, named and its rules written**, before any key is generated. One page, five rules, and the private-key-published field made required in the entry schema.
2. **One persona, end to end**, as a signed agent card plus a marked fixture keypair. The librarian, since it is the least likely to be mistaken for something operational.
3. **The full choreography run once by an agent starting from nothing**, and the transcript published. Discover, fetch, verify the card signature, seal a message, write to the lane, list, fetch, decrypt. Anything that does not work becomes a cross-team brief.
4. **The project lead's own key**, as the first non-fixture entry, with its evidence being the domain attestation and whatever stronger connector is cheapest.
5. **The second and third personas**, only after step 3 has produced something that runs.
6. **A connector that is not the website**, since a register whose every entry rests on one domain has one point of failure and no graph.

Step 3 before steps 4 and 5 is the important ordering. **The acceptance test set on 19 August applies here unchanged**: give a fresh agent the machine-readable index and nothing else, and see whether it can reach a working end-to-end result without reading source or asking a person.

## What This Does Not Try To Be

- **Not a new registry design.** The design is from 5 June and this operationalises it.
- **Not a claim that published keypairs provide identity.** They provide none, permanently, and are fixtures.
- **Not a relaxation of the no-private-keys rule.** The register holds the public half and a flag; the fixture material lives elsewhere.
- **Not a bespoke persona format.** An agent card exists, is signed, and is discoverable.
- **Not an answer to key persistence for rented agents.** Retrieval works only while the key is public.

## Honest Tensions

| Tension | Note |
|---------|------|
| Fixtures make the plumbing real | They also put objects on a trust site that look like identities to anybody skimming, on a domain whose whole argument is about trust, and they are the first thing that will test rules that site published before having any entries |
| Marking rather than hiding | Marking is honest and it means the site publishes something it tells you not to rely on, which is a subtle message to land |
| Adopting the agent card format | It brings tooling and a signature model, and it binds the personas to a specification that is moving and whose canonical path has already changed once |
| Workflow identity as the notary | It is attested and available now, and it makes the register depend on a platform the corpus elsewhere treats as a counterparty risk |
| The domain attestation | It is the cheapest evidence and it makes the entire register only as good as one deployment pipeline and one unrecoverable write key |
| Publishing a key past push protection | The bypass is auditable and correct here, and doing it once normalises a control the same team relies on everywhere else |

## Open Questions

| Question | Notes |
|----------|-------|
| What is the fixture class actually called? | Fixture is the proposal; the word must not suggest a weaker identity |
| Does a fixture get an entry in the register at all? | A flagged entry is queryable; a separate list is unmistakable |
| Which connector comes second? | The register has no graph until an entry rests on two independent sources |
| Who escrows the register vault's write key? | A frozen key register can never retract, which is worse than not existing |
| Does the agent card carry the mandate? | Cards already declare scope of authority, which is the second brief's subject |
| What bounds a fixture's public inbox? | The published rules require records to be size-bounded, and an account-less lane with a published key is where that will be tested first |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 5 Jun | `v0.32.4__dev-brief__sg-send-pki-public-key-registry-on-vaults.md` | The registry design this operationalises, including the rule that the register holds no private keys |
| 4 Jun | `v0.32.3__arch-brief__sg-send-nhi-2.0-trust-and-identity-web-of-trust-agent-trust-scores.md` | The trust model whose vouching signals are the evidence grammar |
| 16 Jun | `v0.33.38__arch-brief__sg-send-hermes-fully-ephemeral-vault-native-agent-nhi-2.0-pki.md` | The ephemeral agent whose keys are fetched rather than kept, which is the bootstrap flow at scale |
| 19 Aug | `v0.33.60__arch-brief__append-lane-is-shipped-and-account-less-four-tiers-and-five-corrections.md` | The shipped lane, the four tiers, and the proposed address derivation whose boundary this keeps |
| 19 Aug | `v0.33.60__strategy-brief__bootstrap-trap-every-workaround-hands-over-a-larger-identity.md` | The loop that retrieval sidesteps only while the key is public |
| 19 Aug | `v0.33.60__cross-team-brief__pki-site-review-mandate-is-the-gap-registry-is-the-missing-half.md` | The absent revocation and directory that a transparency log partly answers |
| 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | Why the notary must be a workflow and cannot be the persona |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The register was designed on 5 June and today's work is operationalisation rather than design |
| 2 | That design already supplies clues-not-storage, two-level trust, self-declaration granting nothing, and caller-side resolution |
| 3 | A keypair with a published private half provides no authentication and no confidentiality, permanently |
| 4 | Such objects are fixtures, and a fixture can neither be promoted to a real key nor revoked, since revocation is a signed append and the signing key is public |
| 5 | The register keeps its no-private-keys rule; the fixture material lives in a separate marked vault |
| 6 | Whether the private half is published is a required field and the most consequential evidence an entry carries |
| 7 | A fixture's append lane is a public inbox, because anybody holding the published private key can decrypt it |
| 8 | Evidence is appended by the asserter to its own record and never to the subject's, which is the 2019 keyserver rule and the first of four the registry site already publishes |
| 9 | The persona format already exists as a signed agent card, and its specification says a card should not carry credentials |
| 10 | The workflow signing hypothesis is implemented, issues certificates that expire in minutes, and is already applied to agent cards |
| 11 | Push protection blocks private keys by default, and publishing them inside vault ciphertext evades that control rather than satisfying it |
| 12 | Retrieval replaces persistence only while the key is public, so the 19 August persistence question stays open |

---

## Sources

- The agent card as a JSON manifest published at a well-known path declaring an agent's identity, capabilities, skills, endpoint and authentication requirements, the addition of signed cards using JSON Web Signature in version 1.0, and the specification's statement that a card should not include sensitive credentials: https://github.com/a2aproject/A2A/blob/main/docs/specification.md and https://aigrowthagent.co/articles/a2a-protocol-explained-2026/
- The finding that the canonical discovery path changed and that roughly a quarter of published cards remain at the older path where a compliant client will not look, together with the specification naming a curated registry as a legitimate discovery route: https://apievangelist.com/2026/07/29/most-published-agent-cards-are-not-actually-a2a/
- Keyless signing driven by a workflow identity token, with short-lived certificates issued by a certificate authority, the signing key discarded after use, and the event recorded in a public transparency log, plus the general availability of artifact attestations and the tightening default posture for public repositories: https://tenki.cloud/blog/github-actions-artifact-attestations-slsa and https://www.systemshardening.com/articles/cicd/sigstore-keyless-signing/
- The implementation that signs agent cards with a workflow identity, where successful verification reveals the repository and workflow that produced the signature: https://github.com/sigstore/sigstore-a2a
- Secret scanning coverage of generic, SSH and PGP private keys as non-partner patterns, push protection enabled by default for public repositories, and the three resolutions available on a blocked push with every bypass logged: https://www.securityscientist.net/blog/12-questions-and-answers-about-github-secret-scanning/ and https://github.blog/changelog/2026-06-17-secret-scanning-updates-june-2026/
- The shipped append lane surface and its four capabilities, being an append token that writes one lane, an enumeration key that lists, fetches and marks, a write key that configures and purges, and a private key held client-side: https://sgit.ai/llms.txt
- The shipped public key infrastructure commands and their stated gaps, including that there is no key revocation or rotation workflow, no certificate revocation list, no expiry and no revoke command, and no web of trust and no directory, together with the named algorithms of RSA-OAEP at 4096 bits for encryption, ECDSA P-256 for signing and AES-256-GCM for content: https://sgit.ai/docs/pki
- The end-to-end vault messaging procedure from keygen through configure, encrypt, write, list, fetch, decrypt and mark-processed, and the statement that the client derivation turning a public key into a lane address is proposed rather than shipped: https://sgit.ai/docs/vault-messaging
- The limitations page recording, under what the public key infrastructure does not do yet, that lane addressing is not wired end to end, that the intended model is an append token derived as the hash of the public key, that the server side ships, that no shipped command emits that token and that a token is therefore agreed out of band today: https://sgit.ai/docs/limitations
- The key registry site publishing, before any registry exists, the four rules derived from the 2019 keyserver failure, being that only the owner writes to their own record, that revocation is a signed append rather than a deletion, that records are size-bounded, and that every entry is signed by something a reader can check: https://pki.sgit.ai

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).