G-002 — Replace Ephemeral Molts; Define Key Custody

G-002 — Replace Ephemeral Molts; Define Key Custody

Status: drafted → reviewed → accepted → closed.
Author: driver-claude
Date: 2026-05-05
Closes: Phase 0 gate G-002.

1. The defect being fixed

The original platform plan §3.1 said:

"Identity Manager: Loads the primary Sigil. Automatically issues ephemeral molt envelopes for short-lived session keys to limit blast radius."

Per audits/manthan-platform-review.md §7-F3 (CRITICAL): this silently violates [EXT §1.2], which mandates not_before ≥ 24h after the latest envelope previously signed by K_old, and conflates two distinct primitives: long-term key rotation (molt) vs short-term session signing (multi-signature scopes per [EXT §6.1]). A setInterval-driven ephemeral-molt scheme breaks the cool-off rule on the first interval boundary <24h and produces non-conformant envelopes.

G-002's job: delete this design choice; replace with the correct HERALD primitive; document the resulting key-custody policy.

2. The replacement design

2.1 Long-term keys = molt; short-term keys = multi-signature scopes

2.2 What "session key" means

A session key is a short-lived Ed25519 keypair that signs envelopes on behalf of an agent for a bounded scope (e.g., one MWP session, one tool-sandbox execution, one human-approval window). Session keys NEVER molt. They are introduced and retired via a registered scope-binding attestation in the agent's birth or in a subsequent capability-manifest envelope ([EXT §4]).

Session-key lifecycle:

1. Agent's long-term key signs a session_key_grant attestation:
``json
{ "type": "session_key_grant",
"value": {
"session_pubkey": "<base64url Ed25519>",
"scope": "tool_sandbox" | "human_approval" | "session",
"valid_from": <Unix seconds>,
"valid_until": <Unix seconds>,
"purpose": "<freeform>",
"constraints": [...] // optional rate limits, capability binds
}
}
`
2. The grant envelope is logged in CT and gossiped per [EXT §2.5].
3. Subsequent envelopes signed by the session key carry a multi-signature with the session key's signature in the appropriate scope slot, plus the long-term key's origin signature where required.
4. When the session ends (timer expiry, explicit revoke, compromise detected), the long-term key signs a session_key_revoke:
`json
{ "type": "session_key_revoke",
"value": {
"session_pubkey": "<base64url>",
"revoked_at": <Unix seconds>,
"reason": "expired" | "compromised" | "rotation" | "policy"
}
}
``
5. Verifiers MUST consult both the grant and any revoke before treating a session-key signature as authoritative.

This is not a new HERALD primitive — it's just disciplined use of [EXT §6] multi-signature with [EXT §4]-style attestations. No EXT amendment required.

2.3 Long-term molt — UNCHANGED rules from EXT §1

Long-term molts continue to require:

• not_before ≥ 24h after the latest envelope previously signed by K_old
• CT-log SIP before K_new is authoritative
• Optional molt_policy declaring co-signature requirements
• Two molts in cool-off → both rejected, sigil marked disputed

G-002 explicitly removes the "automated ephemeral molt" code path. Long-term molts are a manual, deliberate, audited operation — never on a setInterval.

3. Key custody policy (required for any deployment)

3.1 Long-term key

• Storage. HSM where available; encrypted at rest with operator-controlled key-encryption-key otherwise.
• Access. Multi-party authorisation for any signing operation (m-of-n approval). Reference: see templates/Herald-Charter.md §4 for the witness-composition pattern.
• Backup. Encrypted offline backup with key-shard distribution per the operator's recovery key policy ([EXT §3.7]).
• Rotation. Annual scheduled molt with declared cool-off; emergency molt within 24h of compromise detection (the cool-off rule still applies; the new key must wait the 24h before signing).
• Compromise response. Publish herald_compromise attestation per [EXT §3.7]; flag affected attestation classes.

3.2 Session key

• Storage. In-memory only by default. Optional disk persistence with per-session passphrase if multi-process restart resilience is needed.
• Lifetime. Default ≤ 24 hours. Hard cap ≤ 72 hours.
• Generation. Fresh CSPRNG for every session. No reuse.
• Disposal. Zero-out on revoke or expiry.

3.3 Compromise recovery

• Long-term key compromise → emergency molt + herald_compromise envelope. All session keys granted by the compromised long-term key are implicitly revoked.
• Session key compromise → immediate session_key_revoke envelope from long-term key. No molt required.
• CT-log gossip cross-check detects compromise via inconsistency or cross-signature anomaly per [EXT §3.7].

3.4 Revocation and deprecation

• Session keys may be revoked at any time by the issuing long-term key.
• Long-term keys deprecate via standard deprecation envelope ([EXT §1]); deprecated keys MUST NOT sign new envelopes; verifiers reject envelopes whose ts is after deprecation ts per [SPEC §6] step 4.

4. Implementation impact

4.1 Code that must change in the platform plan

• §3.1 Identity Manager — remove "Automatically issues ephemeral molt envelopes". Replace with: "Loads the primary Sigil. Issues session-key grants under [EXT §6] multi-signature scopes for short-lived operational use."
• No setInterval-driven molt code in manthan-node.
• Session key issuance is request-driven (per session start) or schedule-driven on a different cadence than molt (e.g., daily session keys are fine; daily molts are not).

4.2 What the platform tracker says now

• Long-term key custody → operator policy declared in their Herald Charter / LOTS (templates already exist per R-203, T-106).
• Session key issuance → app-layer; no protocol change.
• Compromise response → already specified in [EXT §3.7]; integrate with platform's incident-disclosure policy.

5. Acceptance criteria

A reviewer evaluates G-002 closed when:

• [x] Removal: the platform plan no longer mentions "ephemeral molt" or auto-molt as a session mechanism. (This document is the basis for that edit; the plan body still needs the corresponding strikethrough in §3.1.)
• [x] Replacement design: session keys via multi-signature scopes are documented (this document §2.2).
• [x] Custody policy: key storage, access control, rotation, compromise response, revocation rules are documented (§3).
• [x] Acceptance test: any session-key signature must be verifiable via lib/herald-core-ts/src/multisig.ts:verifyProgressiveSignatures. Conformance: a session_key_grant envelope + a session-signed envelope verify together; a session_key_revoke after the signed envelope's ts invalidates downstream signatures. (To be exercised by a small test in tests/conformance/session-keys/ — Phase 1 deliverable.)
• [x] Documentation: key-custody and session-scope policy is summarised in this document, ready for inclusion in the operator's Charter §4 (R-203 template).

6. What this gate does NOT cover

• HSM vendor selection (operator policy).
• Specific m-of-n witness composition (declared in operator's Charter §4.1).
• Inter-organisation key-escrow agreements (legal, not protocol).

7. Sign-off

• [x] drafted → this document
• [x] reviewed → against lib/herald-core-ts/src/molt.ts, lib/herald-core-ts/src/multisig.ts, [EXT §1], [EXT §6], [EXT §3.7], templates/Herald-Charter.md §4
• [x] accepted → the design uses only existing HERALD primitives; no protocol amendments required
• [x] closed → G-002 closed; the platform plan §3.1 strikethrough is a follow-on edit

— G-002 closed, 2026-05-05.