FABRIC-2.md: identity-range allocation is first-touch, not a hash formula; identity is a CA-signed cert

Dropped the hash-modulo-MAX_IDENTITIES approach: there is no way to bound
how many identities might ever exist, so no population size can be
pre-divided into slots regardless of hash function. Resolution: first
time an identity is seen, claim a range at the SSD's existing free-space
frontier (g.total_user_lbn, already used by every device attach) sized
to whatever it needs, write the assignment into the drive's own map;
every later visit just reads it back. No central directory, no quota,
matches Section U's existing requirements exactly.

Identity itself is a certificate signed by this project's own (not yet
created) CA root, extending Milestone 6's PKI design to users instead of
inventing a separate mechanism. Derivation-relevant value is the cert's
embedded pubkey, not its raw bytes -- a renewal shouldn't relocate an
already-allocated range.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn

FABRIC-2.md

@@ -4015,11 +4015,45 @@ kernel-read code) — reading/writing a real GPT partition table from `src/stark
 unstarted work this decision required, before `blkio_usb.c` could hand
 `blk_subsys_attach_device()` a correctly-offset device view.~~
 
-- [ ] Design the identity→block-range derivation function's exact input/output (Section V
-      area A open point: currently zero decisions made, not even a function signature)
-- [ ] Decide what "identity" means concretely as an input — the Ed25519 public key itself,
-      a hash of it, something else
-- [ ] Implement the derivation function
+**Superseded 2026-08-25 — identity→range is first-touch allocation, not a computed hash
+mapping.** The original framing (below, struck through) assumed a hash-modulo-`MAX_IDENTITIES`
+formula; dropped once the actual constraint was named directly: **there is no way to know how
+many identities might ever exist**, so no population size can be pre-divided into slots at all,
+regardless of how the hash is computed. Resolution: no formula, no `MAX_IDENTITIES`. First time
+an identity is ever seen (its drive's map is empty), claim a range starting at the SSD's
+existing free-space frontier — `block_subsystem.c`'s `g.total_user_lbn`, the same monotonic
+"next free LBN" every `blk_subsys_attach_device()`/`blk_subsys_add_raw_device()` call already
+appends against — sized to whatever the identity needs right now (open-ended, no quota,
+matching Section U item 1), and write that one-time assignment into the drive's own map
+(Section U item 4). Every later visit reads the range straight out of the drive's map and
+trusts it; the SSD itself never re-derives or centrally directories anything. This resolves the
+unbounded-population problem (allocation is append-only against a growing frontier, never
+pre-divided), keeps Section U item 4's "the SSD doesn't need to remember anything about you
+until you're back" property exactly, and still satisfies "identity-derived, not
+attach-order-derived" (Section U item 3) because the lookup key is the identity, not physical
+insertion order.
+
+**Identity itself, decided the same session: a certificate signed by this project's own
+(not yet created) CA root — extending Milestone 6's existing PKI design (kernel-embedded
+cert validating capsules) to user identity, not a separate mechanism.** The derivation-relevant
+value is the cert's *embedded Ed25519 public key* specifically, not the cert's raw bytes or
+serial number — a cert can be reissued (renewed, new serial, new validity window) while the
+underlying keypair stays the same, and keying off the pubkey means a renewal doesn't silently
+relocate a user's already-allocated range. The kernel verifies the cert against the CA chain
+(Milestone 6's own not-yet-built verification path) before trusting a drive's self-reported map
+as genuinely belonging to that identity — otherwise anyone could hand-edit a drive's map and
+claim someone else's already-allocated blocks.
+
+~~Design the identity→block-range derivation function's exact input/output (Section V area A
+open point: currently zero decisions made, not even a function signature). Decide what
+"identity" means concretely as an input — the Ed25519 public key itself, a hash of it,
+something else. Implement the derivation function.~~
+
+- [ ] Implement the CA-signed-cert verification path (Milestone 6 dependency — the cert chain
+      validator doesn't exist yet either)
+- [ ] Implement the first-touch allocation function: given a verified identity pubkey and a
+      requested block count, either read an existing range from the drive's map or claim a
+      new one at `g.total_user_lbn` and write it back
 - [ ] Design the on-drive block-map format (Section U item 4) — what it records (block
       ranges claimed? individual block liveness? something else), how it's serialized
 - [ ] Implement writing the block-map to a drive