make sshsigchain the only portable sigchain format
This commit is contained in:
parent
9e5871d02a
commit
73500e1944
15 changed files with 812 additions and 1603 deletions
|
|
@ -1,9 +1,10 @@
|
|||
# ADR 0018: Linked SSHSIGCHAIN v2
|
||||
# ADR 0018: Linked SSHSIGCHAIN v1
|
||||
|
||||
## Status
|
||||
|
||||
Accepted for the new generic core and geth keychain profile. Legacy static
|
||||
sigchain publication is deprecated pending explicit v2 command migration.
|
||||
Accepted for the generic core and geth keychain profile. The pre-standard
|
||||
test-only static workflow is removed; it is not an alternate format or a
|
||||
compatibility path.
|
||||
|
||||
## Context
|
||||
|
||||
|
|
@ -14,7 +15,7 @@ rollback, and fork semantics inadequate for a trust foundation.
|
|||
|
||||
## Decision
|
||||
|
||||
Geth adopts SSHSIGCHAIN v2 as the replacement design:
|
||||
Geth adopts SSHSIGCHAIN version 1 as its one portable signed-chain 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
|
||||
|
|
@ -31,11 +32,11 @@ not a geth transport.
|
|||
|
||||
## Consequences
|
||||
|
||||
The v2 core can be published and implemented by applications without importing
|
||||
The 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.
|
||||
The old static bundle code and commands are deleted rather than supported beside
|
||||
SSHSIGCHAIN. There is no migration format because the repository has not been
|
||||
deployed. Head persistence and later witness/transparency support remain
|
||||
follow-up work; neither is implied by a single signed checkpoint.
|
||||
Loading…
Reference in a new issue