Negative vectors: embedded-key rejection (pairs with @veritasacta/verify 0.4.0)#5
Open
tomjwxf wants to merge 1 commit into
Open
Negative vectors: embedded-key rejection (pairs with @veritasacta/verify 0.4.0)#5tomjwxf wants to merge 1 commit into
tomjwxf wants to merge 1 commit into
Conversation
…ify 0.4.0)
Adds four fixtures under negative/embedded-key-rejection/ that a conformant
implementation of draft-farley-acta-signed-receipts MUST reject when no
external key source is provided:
001 — Passport envelope with payload.public_key
002 — v1 flat artifact with top-level public_key
003 — v2 structured with payload.verification_key
004 — Passport envelope with payload.verification_jwk (full JWK)
Each fixture carries a valid-looking Ed25519 signature (placeholder hex,
not real crypto) that would verify if the verifier accepted embedded
keys. The rejection is a policy check preceding signature validation,
not a signature-validity check. A signature that verifies under an
attacker-chosen key is worse than no signature at all.
Pairs with:
- @veritasacta/verify 0.4.0 (rejects embedded keys by default,
deprecated --allow-embedded-key escape hatch for 0.4.x only)
- draft-farley-acta-signed-receipts-02 Security Considerations
(normative "MUST NOT accept a verification key transported inside
the receipt unless independently anchored")
Triggered by the desiorac review on GetBindu PR #459 that publicly
surfaced the gap.
Co-Authored-By: Claude Opus 4.7 (1M context) <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
2 participants
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.
What this adds
Four fixtures under
negative/embedded-key-rejection/that a conformant implementation ofdraft-farley-acta-signed-receiptsMUST reject when no external key source is provided.payload.public_keypublic_keypayload.verification_keypayload.verification_jwk(full JWK)Each carries a valid-looking Ed25519 signature (placeholder hex, not real crypto) that would verify cleanly if the verifier accepted embedded keys. The rejection is a policy check preceding signature validation. A signature that verifies under an attacker-chosen key is strictly worse than no signature at all.
Why
@desiorac surfaced the gap publicly on GetBindu PR #459 last week. Root cause:
draft-farley-acta-signed-receipts-01is silent on key distribution, which permits implementers to add an embedded-key fallback that violates the issuer-blind property the spec is designed to provide.This PR pairs with:
@veritasacta/verify0.4.0 (coming this week) — rejects embedded keys by default, deprecated--allow-embedded-keyescape hatch for one release cycle.draft-farley-acta-signed-receipts-02(coming this week) — adds the normative MUST NOT in Security Considerations.Together these three artifacts close the gap across spec, reference verifier, and conformance surface.
Expected verifier outcome
For all four fixtures, a 0.4.0+ verifier invoked as:
MUST exit with status
2(undecidable) and emit an error identifying the embedded-key pattern as the reason.With
--allow-embedded-key(deprecated, 0.4.x only): verifier accepts the embedded key for backward compatibility during migration. Tests at this mode pass signature verification against the (placeholder) signature, which fails for unrelated reasons since the signatures in fixtures are placeholder hex.Verification
_metablock on each fixture documents expected outcomeRelated
draft-farley-acta-signed-receipts-02Security Considerations@veritasacta/verify0.4.0 ships the rejection logic