A DSSE envelope is a small signed wrapper, short for Dead Simple Signing Envelope, that carries a payload, a type label for that payload, and one or more signatures. Attestations use it because the signature covers both the bytes and the declared type, so a payload cannot be passed off as something else.
What is inside the envelope
The DSSE specification defines a few fields:
| Field | Purpose |
|---|---|
| payload | The base64 encoded body being signed |
| payloadType | A string saying what kind of payload this is |
| signatures | An array of signature objects |
| keyid | Optional hint about which key signed |
| sig | The base64 encoded signature |
For attestations, the payload is an in-toto Statement serialized as JSON. The envelope handles authentication and serialization, and the Statement above it binds the claim to an artifact. In-toto describes these as separate layers: envelope, statement, predicate and bundle.
What gets signed
The signature is not made over the raw payload. DSSE defines a pre-authentication encoding, written PAE, and signs that:
PAE(type, body) = "DSSEv1" + SP + LEN(type) + SP + type + SP + LEN(body) + SP + body
Here LEN is the ASCII decimal byte length and SP is a single space. Because the type and the length of each field are inside the signed bytes, the type is authenticated rather than being a loose label next to the signature. The length prefixes also give each field a clear boundary.
The protocol text advises against generic payload types such as application/json, because two applications might share an encoding but read the payload differently. That is a type confusion risk, and a specific type string reduces it.
The rule implementers must follow
The spec says the bytes that were verified must be the same bytes handed to the application. Do not parse the envelope again after verification to pull out the payload. A second parse can disagree with the first, and that gap is where bugs live.
Verification in five steps
- Decode the payload, type, signature and key id, and reject on failure.
- Optionally narrow the candidate keys using the key id.
- Check the signature over PAE of the type and payload.
- Reject any payload type you do not support.
- Parse the payload according to its type.
DSSE inside Sigstore bundles
A Sigstore bundle can hold a DSSE envelope for attestations. The bundle format requires that such an envelope contains only a single signature, even though DSSE itself allows several.
Where Safeguard fits
Attestations are one input to release decisions. Safeguard's compliance and evidence automation helps keep the records around those decisions organised for audits.
Quick check
Is DSSE a signing algorithm?
No. It is an envelope format and an encoding rule. You still choose the key type and signature algorithm.
Why not just sign the JSON?
Signing raw JSON leaves the type unauthenticated and depends on every verifier serializing it the same way. DSSE signs exact bytes plus the declared type.
Sources
Last reviewed: 19 October 2026.
