A key_id leaks its label — federation-level moderation must address the key fingerprint

[emooreatx]

Federation-scoped moderation and de-admission actions currently name a key_id. A key_id is not opaque.

The leak

ciris-verify-core fedcode.rs::derive_key_id:

/// Derive a collision-free, verifiable `key_id` = "<label>-<fingerprint>".
/// `label` is lowercased and reduced to [a-z0-9-] (cosmetic). `fingerprint`
/// is the first KEY_ID_FINGERPRINT_LEN base32 chars of sha256(ed25519_pubkey).

The label is the keystore alias, in cleartext. ciris-agent-bootstrap-mplbdbzbed is benign; real deployments will carry frank-laptop or acme-node-3. So an action that names a key_id publishes who it acted on to everyone it replicates to — no directory body required.

That is the wrong default for a federation-wide action against a person.

Address the fingerprint instead

Use the full sha256(ed25519_pubkey) — already the primitive derive_key_id computes, already public in truncated form, and carrying no label.

• Stable for the life of the key, not the life of a record. A node holding the identity recomputes and enforces; a node that does not can still relay the action without learning who it names.
• Do not use the record's content hash. It changes on re-scrub or supersede (adopt_scrub_upgrade does exactly that), so a ban would lapse the moment the subject re-mints their record.
• Evasion costs a new key — a different identity that abandons every attestation and all standing it had. That is the correct price, and content-hash addressing would have made it free.

What this does and does not buy

It hides the label, not the identity. Anyone holding the directory body can still join fingerprint → key_id. The guarantee is narrower and worth stating exactly: the action itself carries nothing, and joining requires already holding the record — which under hash-first retention (#552) most of the federation will not.

Overselling this as anonymity would be wrong, and would invite someone to rely on it for more than it does.

Cross-repo

Persist owns the admission and moderation gates, so the addressing change likely needs a companion there — filed as CIRISPersist#784.

Related: #552 · CIRISPersist#784

[emooreatx]

Persist has answered both questions. Summarising here because it changes this from "addressing change" to "coordinated cut", and because one finding is a trap edge could walk into on its own.

It needs a migration, not a query change

Persist's gates key on key_id pervasively — federation_keys.key_id is the PRIMARY KEY and every read goes through it. pubkey_ed25519_base64 has no index and no fingerprint column exists, so resolving fingerprint → key_id today is a full table scan computing SHA-256 per row. A stored, indexed column is required.

revoked_key_id cannot carry it, for two reasons

1. FK. revoked_key_id TEXT NOT NULL REFERENCES federation_keys(key_id) — a fingerprint fails the constraint. And that FK is not incidental: it encodes you cannot revoke a key that is not in the directory. Fingerprint-addressing deliberately relaxes that (you could ban a key whose record you have never seen), which may be desirable but is a design decision, not plumbing.
2. It is inside the signed bytes (REVOCATION_BINDING). Overloading its meaning changes what existing signatures attest to. So this needs a new bound member, never an overload — an overload would be a silent type pun on a signed plane.

The naming trap — flagging for edge as much as persist

Persist already has accord_key_fingerprint(), and it computes a different digest: sha256(pubkey_base64_text) — over the ASCII of the base64 string. derive_key_id computes sha256(raw 32 pubkey bytes). Same word, different preimage.

Adding a third would give this codebase three distinct "fingerprints": the truncated base32 suffix inside key_id, verify's raw-bytes digest, and persist's hex-over-base64 helper. The existing name will actively recruit the wrong one — someone will reach for accord_key_fingerprint() because it is right there and named correctly.

So: do not call it a fingerprint. Name the preimage in the identifier — ed25519_pubkey_sha256, or a newtype that cannot be constructed from a base64 string. This is the "one variable, two jobs" shape with a naming collision on top, and the two values are indistinguishable at the type level today.

Edge will hold to the same rule on its side.

Scope is three planes

Revocation.revoked_key_id, CommunityMembershipRevocation.removed_identity_key_id, and Attestation.attested_key_id where the dimension is moderation:*. Fixing only revocation leaves two-thirds of the disclosure in place.

Status

Blocked on the coordinated cut, and correctly not urgent. Agreeing with persist's read: a migration plus a new bound member on three signed planes, with a preimage move in it, is not a v38.8 drive-by.

The one thing worth doing now is settling the member's shape and name, because adding it before those planes replicate widely is much cheaper than after — and universal promotion is what makes them replicate widely.

Unblocking the other three (#552, #553, #554) and proceeding there.