docs(adr): T-057 — the tenant signs what it asserts, the platform attests it - #137
Merged
Merged
Conversation
…ests it Records the owner's decision on GT-588 key custody, adopting their proposal for one of the two signing identities and refusing it for the other. The proposal was that each tenant own its signing mechanism, in tenant configuration. That is coherent with T-056 and it is adopted for the ISSUER key: "this tenant approved this gate" is the tenant's own claim, so it is the tenant's key, alongside the gate matrix and the artifact overlay. Per-tenant keys make custody HARDER, not easier -- N keys to store and rotate -- and that cost is accepted deliberately, because it is what makes each tenant independent. It is refused for the TRANSPARENCY SERVICE key. RFC 9943 puts that authority in a separate entity, and `MerkleTransparencyService` already carries both as distinct fields with a comment saying why: a statement and a receipt produced with the same key are "a self-assertion with added ceremony". A tenant signing its own receipt could rewrite its history and re-sign it -- the signature would still catch an accident and would stop proving anything to a third party, which is the case the owner said matters. Third point, written down because both mistakes are easy: NEITHER key is what makes the trail immutable. That is the append-only audit table (`MakeAuditEntriesAppendOnly`). The signature adds attributable provenance, not immutability -- so unsigned-but-append-only is not untrustworthy, and signed-but-mutable is not proof. Today's state is stated rather than left implicit: until per-tenant issuer keys exist, the platform signs for everyone, which is weaker than this decision. Registered in DECISIONS.md/.es.md -- the inventory derives the count from that registry, not from the ADR files, so an ADR that is not registered there is invisible to it. The generated blocks were regenerated (57 decisions). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Records the owner's decision on GT-588 key custody — adopting the proposal for one of the two signing identities, and refusing it for the other.
The proposal, and where it lands
"Each tenant should be responsible for its own signing mechanism, in tenant configuration."
Per-tenant keys make custody harder, not easier — N keys to store and rotate rather than one. That cost is accepted deliberately: it is what makes each tenant independent.
Why the second one is refused
RFC 9943 puts that authority in a separate entity, and
MerkleTransparencyServicealready carries both as distinct fields with a comment explaining it: a statement and a receipt produced with the same key are "a self-assertion with added ceremony". The signature would still catch an accident — and would stop proving anything to a third party, which is the case that matters here.The third point, written down because both mistakes are easy
Neither key makes the trail immutable. That is the append-only audit table (
MakeAuditEntriesAppendOnly). The signature adds attributable provenance, not immutability — so unsigned-but-append-only is not untrustworthy, and signed-but-mutable is not proof.Today's state is stated rather than left implicit: until per-tenant issuer keys exist, the platform signs for everyone, which is weaker than this decision.
One thing worth knowing about this repo
The doc inventory derives its decision count from
DECISIONS.md, not from the ADR files — so an ADR that is not registered there is invisible to it.--checkpassed with the file present and unregistered. Registered in both languages; generated blocks regenerated (57 decisions).🤖 Generated with Claude Code