Static read-through audit of crates/dpp-evidence. JWS verification is solid (alg pinning, verify_strict, JCS content-binding). Two verified findings.
1. Transfer chain treats missing signatures as "nothing to verify yet"
Location: src/verify/transfer_chain.rs:50-68
Issue: A TransferRecord with from_signature/to_signature == None is unconditionally treated as not-yet-signed, without checking completed_at/rejected_at/cancelled_at.
Failure scenario: If a dossier-producing node marks a transfer completed_at: Some(...) but signatures are absent (workflow bug), verify_transfer_chain reports Pass with zero cryptographic checks performed — silently defeating the "zero trust in the issuing node" goal for the transfer-chain proof specifically.
2. Public-key fallback triggers on any kid-resolution failure, not just legacy tokens
Location: src/jws/verify.rs:164-174
Issue: resolve_public_key's doc says the primary-key fallback exists "for JWS tokens signed before kid was added," but the code falls back whenever fingerprint lookup fails for any reason — including a kid that no longer matches any authorized key (revoked/rotated).
Failure scenario: Not an auth bypass (the real Ed25519 check still runs and a signature from a revoked key still fails), but it silently substitutes the current primary key rather than surfacing the more accurate "kid does not resolve" diagnosis — worth fixing for correct error attribution.
Static read-through audit of
crates/dpp-evidence. JWS verification is solid (alg pinning, verify_strict, JCS content-binding). Two verified findings.1. Transfer chain treats missing signatures as "nothing to verify yet"
Location:
src/verify/transfer_chain.rs:50-68Issue: A
TransferRecordwithfrom_signature/to_signature == Noneis unconditionally treated as not-yet-signed, without checkingcompleted_at/rejected_at/cancelled_at.Failure scenario: If a dossier-producing node marks a transfer
completed_at: Some(...)but signatures are absent (workflow bug),verify_transfer_chainreportsPasswith zero cryptographic checks performed — silently defeating the "zero trust in the issuing node" goal for the transfer-chain proof specifically.2. Public-key fallback triggers on any kid-resolution failure, not just legacy tokens
Location:
src/jws/verify.rs:164-174Issue:
resolve_public_key's doc says the primary-key fallback exists "for JWS tokens signed before kid was added," but the code falls back whenever fingerprint lookup fails for any reason — including akidthat no longer matches any authorized key (revoked/rotated).Failure scenario: Not an auth bypass (the real Ed25519 check still runs and a signature from a revoked key still fails), but it silently substitutes the current primary key rather than surfacing the more accurate "kid does not resolve" diagnosis — worth fixing for correct error attribution.