41 lines
1.7 KiB
Markdown
41 lines
1.7 KiB
Markdown
|
# ADR 0018: Linked SSHSIGCHAIN v2
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted for the new generic core and geth keychain profile. Legacy static
|
||
|
|
sigchain publication is deprecated pending explicit v2 command migration.
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
The prior static JSONL keychain flow replayed records after sorting mutable
|
||
|
|
timestamps and used a downloaded allowed-signers projection to verify its own
|
||
|
|
checkpoint. That permits self-bootstrapping trust and makes revocation,
|
||
|
|
rollback, and fork semantics inadequate for a trust foundation.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
Geth adopts SSHSIGCHAIN v2 as the replacement design:
|
||
|
|
|
||
|
|
- root trust is an explicit `(chain ID, profile, namespace, root key)` tuple;
|
||
|
|
- records are linearly ordered by sequence and linked by a digest over their
|
||
|
|
signed content and SSHSIG signature;
|
||
|
|
- the initial root is only a genesis requirement, not a permanent bypass;
|
||
|
|
- profile authorization runs against the causally preceding state;
|
||
|
|
- key lifecycle is represented by causal add/revoke records, not timestamp
|
||
|
|
validity fields; and
|
||
|
|
- payloads use deterministic binary codecs with a strict round-trip check.
|
||
|
|
|
||
|
|
The generic core is transport-independent. Geth continues using Iroh for all
|
||
|
|
node-to-node communication; SSH remains an identity/signature integration and
|
||
|
|
not a geth transport.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
The v2 core can be published and implemented by applications without importing
|
||
|
|
geth's resource model. Geth's keychain profile is intentionally narrow and
|
||
|
|
tested against self-bootstrap, fork, and backdated-revocation attacks.
|
||
|
|
|
||
|
|
Existing static v1 bundles cannot safely migrate in place. Operators must pin a
|
||
|
|
new v2 trust tuple and create a new genesis chain. Head persistence and later
|
||
|
|
witness/transparency support remain follow-up work; neither is implied by a
|
||
|
|
single signed checkpoint.
|