Repository navigation
Answer R21's open half: no protected mechanism, and policy identifiers stay unsigned - #93
Merged
Merged
Conversation
…tinct Slice 024 proposed the signed receipt field set for review and built the default until cleared. Nothing cleared it, so slice 120's AC3 could not be met. Both questions are now answered from published standards. Does the field set reproduce a third party's protected mechanism? No, because it contains no mechanism anyone owns. prev_hash with seq is a forward-integrity hash chain from 1997 and 1998, key_id is COSE kid, scheme occupies COSE alg's role, at is RFC 3339, subject is in-toto's Statement subject, chain_scope is Certificate Transparency's per-log scoping, fingerprint is an RFC 8785 canonical-digest commitment, and decision is XACML's PDP outcome. IETF RFC 9943, Standards Track, June 2026, standardises the whole object class as COSE_Sign1 Signed Statements and Receipts. An open standard for the thing is the strongest available answer to whether it is someone's to own. May policy identifiers enter signed_payload? No, and the existing placement in unsigned meta is confirmed rather than tolerated. SLSA separates externalParameters, untrusted and verified downstream, from internalParameters, platform-set and optional; a policy identifier is the second kind. Field-tier minimisation gives the governing property: the ledger commits to a digest computed before minimisation, so reclassifying a field changes what is disclosed without invalidating a historical entry or reopening a hash. Trinity already holds that commitment as the fingerprint. A downstream verifier can do nothing with a Trinity policy identifier anyway, and decision.basis already names the deciding layer inside the signed bytes. The original hazard holds and is the reason the rule is worth writing down: if policy identifiers ever come from the external authority plane, embedding another party's namespace in immutable signed bytes is exactly what R21 warns about. In meta a namespace change is a metadata change rather than a scheme bump. R21's likelihood drops to Low for the named question and the row above stands for everything else. Signed-off-by: Ayla Croft <aylacroft@proton.me>
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.
Slice 024 proposed the signed receipt field set for review and built "the default until cleared". Nothing cleared it, so slice 120's AC3 could not be met. Both questions are now answered from published standards rather than from instinct.
Does the field set reproduce a third party's protected mechanism?
No, because it contains no mechanism anyone owns.
prev_hash+seqkey_idkidschemealgroleatsubjectchain_scopefingerprintdecisionRFC 9943 (IETF SCITT, Standards Track, June 2026) standardises this whole object class as
COSE_Sign1Signed Statements and Receipts. An open standard for the thing is the strongest available answer to whether it is someone's to own, and it is the same conclusion the project's prior-art pass reached about every other mechanism here.May policy identifiers enter
signed_payload?No, and the existing placement in unsigned
metais confirmed rather than tolerated.externalParameters(untrusted, MUST be verified downstream) frominternalParameters(platform-set, trusted, OPTIONAL). A policy identifier is the second kind.decision.basisalready carries that inside the signed bytes.The original hazard holds and is why the rule is worth writing down: if policy identifiers ever come from the external authority plane, embedding another party's namespace in immutable signed bytes is exactly what R21 warns about. In
meta, a namespace change is a metadata change rather than a scheme bump.The rule, recorded so it is not re-litigated: the signed payload carries the commitment and the decision facts; anything platform-set, revisable, or another party's namespace goes in
meta.R21's likelihood drops to Low for the named question. The original row stands for everything else, and slice 120's AC3 is met.
🤖 Generated with Claude Code