Why is base64-decoding a DSSE envelope's payload and parsing it not verification?

## What the envelope is An in-toto statement is not signed directly; it is wrapped in a **DSSE** envelope — a small JSON object with three parts: - `payload` — base64 of the **serialized statement bytes** - `payloadType` — a media type string; for in-toto attestations, `application/vnd.in-toto+json` - `signatures` — a list, each with a key identifier and a signature value The naive consumer does this: decode `payload` from base64, `JSON.parse` the result, read `predicate`, make a decision. Every step of that is real work and none of it is verification. Base64 is a transport encoding with no secret in it — anybody can produce a payload that decodes cleanly and parses into a well-formed statement claiming whatever they like. ## What the signature actually covers DSSE signs a **pre-authentication encoding** (PAE) of two things: the payload type and the payload bytes. The construction is a version marker followed by the byte length and content of the type, then the byte length and content of the payload, all concatenated with separators. Two properties fall out of that, and both are interview material. **The type is inside the signature.** You cannot take a blob that was signed as one media type and present it as another. Without that binding, a signature produced over some other kind of document could be replayed as if it were an attestation, and a verifier that only looks at the decoded JSON would never notice. This is exactly the failure mode where an envelope with a swapped payload type still "parses" — the parse succeeds because the bytes are still JSON, and the consumer never asked what those bytes were supposed to be. **Length prefixes remove ambiguity.** Because each field's length is signed alongside its content, no attacker can shift the boundary between type and payload to make one concatenation look like another. ## Why bytes, not canonical JSON DSSE deliberately signs the **exact serialized bytes** rather than a canonicalized form of the object. Canonicalization has an ugly history in signature systems: two parsers disagree on duplicate keys, number formatting, or unicode escaping, and a verifier that re-serializes a parsed object before hashing ends up validating bytes it never received. Signing the literal bytes means the thing you verified and the thing you parse are the same octets. The practical consequence for your code is that you must keep the raw decoded bytes around — verify over those, then parse those, and never re-serialize in between. ## The verification order that avoids the trap A correct consumer runs strictly in this sequence, failing closed at each step: 1. Parse the envelope structurally (this much is unavoidable) but treat everything inside as untrusted. 2. Recompute the pre-authentication encoding from `payloadType` and the decoded payload bytes; verify the signature over it against a key or identity your policy accepts. Count how many *trusted* signatures verified; DSSE permits several and says nothing about how many must be good — that threshold is your policy's call. 3. Check `payloadType` equals the in-toto media type. If it does not, this is not an attestation, however valid the signature is. 4. Now parse the payload as a statement, and check `_type` is a statement version you understand. 5. Match a `subject` digest against the artifact you actually hold, under an algorithm you accept. 6. Check `predicateType` is one your policy has a rule for. An unrecognised type is not a pass; it is an absence of evidence. 7. Only now read the `predicate`. Everything before step 2 is untrusted input, and any decision taken on fields read before their step is a bypass. ## The class of bug this prevents The generic shape is *time-of-parse before time-of-verify*: code that routes, logs, caches or filters on a field it has decoded but not yet authenticated. It is easy to introduce accidentally — a helper that pretty-prints the predicate for a build log, a cache keyed on `predicateType`, a metric label taken from the subject `name`. None of those looks like a security decision, and all of them let unverified attacker-controlled data steer behaviour. Keeping one function that returns *either* a verified statement *or* an error, with no path that hands back a parsed-but-unverified one, is what makes the rule enforceable rather than aspirational.