HMAC-SHA256 baseline needs defined key distribution, rotation, and per-session derivation

[rocklambros]

Surfaced during the v0.1.0 review (PR #2). Closely tied to the conformance-baseline conversation in that PR. Filing separately so we can track the crypto details independently.

specification.md §10.1 lists HMAC-SHA256 as the RECOMMENDED default with no key distribution mechanism, no rotation rule, and no per-session derivation. key_id is just an opaque resolver.

The failure mode: reference implementations and copy-paste deployments will use a single hardcoded shared secret per Guardian fleet, since that's the path of least resistance the spec endorses. One Observed Agent compromise lets the attacker mint valid HMACs for every session in the fleet. There's no revocation path, so the only remediation is fleet-wide secret rotation with no protocol-defined mechanism for it.

Proposed direction:

• Per-session HKDF-derived key from a handshake-established secret, so a single session compromise doesn't burn the whole fleet
• Defined key_id resolution flow including a minimum rotation policy in the normative text
• Optional revocation method, could be as simple as revoked_key_ids in subsequent handshakes

Why deferred from v0.1.0: depends on the resolution of the broader Core-baseline conversation in PR #2. If we land minimum-signing in Core, this becomes part of that work. If we don't, this lives as a SHOULD in ACS-Crypto.

References: specification.md §10.1, §10.2, request-envelope.json Signature object

[rocklambros]

Adapter-side data point from #22, related but a step earlier than this issue.

The reference adapters don't sign the envelope at all. No HMAC on the way out, and the example Guardian doesn't verify a signature or check for replays. This issue is about key distribution and rotation once signing is happening. The reference skips signing entirely and leans on transport (conformance.md:28 makes the baseline signature a Core MUST, and :67 says transport doesn't satisfy it).

Why it belongs next to this issue: whatever key-derivation mechanism lands here (the per-session HKDF direction you sketched) has to show up in the reference adapter, or copy-paste deployments inherit an unauthenticated channel and never add signing back. The single-shared-secret failure mode you flagged is the exact thing a no-signing reference pushes people toward, since dropping in one hardcoded secret later is the path of least resistance.

Cross-linked from #22.