Concept: trust-root custody and succession for v1.0 (for review) - #113
Open
avrabe wants to merge 1 commit into
Open
Concept: trust-root custody and succession for v1.0 (for review)#113avrabe wants to merge 1 commit into
avrabe wants to merge 1 commit into
Conversation
The decisions were being made incrementally across three issues and a dozen comments, which is not a form anybody can review -- including the person writing them. This states the problem, the options, the trade-offs and the questions we cannot answer ourselves, in one place, and backs it with typed artifacts rather than prose alone. Nothing here is decided. The document's own position is only about ORDER: build succession first (REQ-SUCCESSION-001), because it is what makes every other custody choice reversible. Every argument in the earlier discussion collapsed into "the first choice is forever" and pushed toward spending more to avoid being stuck -- which is a constraint we can simply remove, cheaply, with no hardware and no upstream dependency. The signing seam (REQ-SIGNERSEAM-001) lands alongside it: `wsc-dsse` already exposes `trait DsseSigner` taking arbitrary PAE bytes, and varve bypasses it by hardcoding `Ed25519DsseSigner::from_bytes`. Both v1.0 paths need that seam, so neither can be evaluated without it. DD-027 records the ordering as `proposed`, not accepted -- it goes to persona review before it goes to a decision.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft for review — nothing here is decided. Four persona reviewers are reading it now.
The custody decisions were being made incrementally across #110, #112 and sigil#268 in a dozen comments. That is not a form anybody can review, including me. This is one document: the problem, the options, the trade-offs, and the questions we cannot answer ourselves.
The document's only actual position: order
Every argument in the earlier discussion collapsed into "the first choice is forever" — and each time, that pushed toward spending more to avoid being stuck (buy the €1130 FIPS device because validation cannot be retrofitted; agonise over the algorithm because consumers pin it by hand).
That constraint is removable, cheaply. Build succession first (
REQ-SUCCESSION-001) and the hardware choice, the validation level and nearly the algorithm all stop being permanent. It needs no hardware, no budget and no upstream decision.The signing seam (
REQ-SIGNERSEAM-001) lands alongside, because both v1.0 paths need it:wsc-dssealready exposestrait DsseSigner { fn sign(&self, pae: &[u8]); … }taking arbitrary PAE bytes, and varve bypasses it by hardcodingEd25519DsseSigner::from_bytes.Tracked, not just prose
DD-027REQ-SUCCESSION-001REQ-SIGNERSEAM-001DsseSignerrivet validatePASS. The trace already earned its keep: it flagged thatREQ-SIGNERSEAM-001mentionedDD-027in prose without a typed link.What I most want challenged
§10 lists five questions I cannot answer myself — including whether CI-signed publication is acceptable at all for a qualified channel, which decides whether Path A's weakness is fatal. Reviewers are being asked to attack the succession mechanism specifically.
Also corrected here:
DD-026rejected keyless partly because the upstream verifier was a stub that failed open. Verified against wsc 0.11.0 source — that premise expired. The question is reopened, not reversed; DD-026's structural half still stands.