Wiki · Concept · Last reviewed June 25, 2026

Dead Simple Signing Envelope

Dead Simple Signing Envelope, or DSSE, is a compact signing-envelope pattern for binding a payload, a payload type, and one or more signatures before the payload is interpreted.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DSSE, in-toto, Sigstore, attestations, AI security, supply chain

Definition

Dead Simple Signing Envelope, usually shortened to DSSE, is a specification maintained in the Secure Systems Lab ecosystem for signing payloads without making the verifier parse the payload first. The DSSE Protocol v1.0.2, dated May 10, 2024, defines a signing algorithm independent of how the signed data is stored or transmitted; its recommended storage form is a JSON envelope.

The design problem is payload confusion. A raw signature over bytes may say that a key signed something, but it does not by itself say how those bytes should be interpreted. DSSE signs both the serialized body and a payload type string, so the verifier can reject unsupported or unexpected payload types before handing the payload to application logic.

How It Works

DSSE signs a pre-authentication encoding of two values: the payload type and the serialized payload body. The protocol's payloadType is an opaque, case-sensitive string intended to identify both the encoding and the schema or meaning of the payload. Its keyid is only an optional hint for finding candidate keys; the protocol warns that it must not be used for security decisions.

The recommended JSON envelope carries three practical pieces: payload, payloadType, and signatures. DSSE does not mandate a particular signature algorithm, key-management system, or payload encoding. It gives signers and verifiers a small convention for what exactly is covered by the signature and when parsing should happen.

Attestation Context

DSSE is especially important around in-toto attestations. The in-toto Attestation Framework describes an envelope layer as the outermost layer of an attestation, responsible for serialization and authentication through digital signatures. Its v1 envelope specification recommends DSSE as the envelope format and protocol.

The in-toto statement layer then says what the signed claim is about: a subject identified by digest, a predicate type, and a predicate body. DSSE authenticates the envelope and payload type; the in-toto statement gives supply-chain meaning to the payload; a policy engine decides whether the signed claim is acceptable.

Sigstore also touches this layer. Sigstore's Cosign documentation says Cosign supports in-toto attestations and that attestation payloads are signed using the DSSE signing spec. In that stack, DSSE is one envelope inside a wider chain of identities, certificates, transparency logs, artifact digests, and policy checks.

AI Artifact Context

AI systems increasingly depend on signed claims about artifacts rather than only signed artifacts themselves. A team may need evidence that a model weight file came from a particular training run, that a container passed vulnerability scanning, that a dataset snapshot was approved, or that an evaluation suite was run against the exact digest promoted to production.

DSSE helps by making those claims carry their own authentication boundary. For a model release, the envelope can protect a statement about the subject digest and predicate type before deployment interprets the predicate. For agent tools, the same pattern can distinguish a signed vulnerability report, build provenance statement, and test result.

Governance Use

A governance workflow should treat DSSE as a carrier of evidence, not as the evidence by itself. The minimum useful record includes envelope bytes, payload type, decoded statement, subject digest, signature verification result, trusted key or identity context, verifier version, policy decision, and review date.

For AI releases, DSSE evidence belongs beside an AI Bill of Materials, SLSA Provenance, model card or system card, evaluation record, and deployment approval. It can help an auditor reconstruct what was claimed about an artifact at release time, but it cannot decide whether the claim is sufficient.

Limits

DSSE does not prove that a predicate is true. A signer can sign a false or incomplete statement. A verifier can trust the wrong key. A deployment gate can accept the wrong payload type. DSSE also does not define a transparency log, identity provider, certificate authority, revocation system, or artifact registry. Those controls must come from surrounding systems such as Sigstore, in-toto policy, SLSA requirements, or local release governance.

The most common misuse is ceremonial verification: accepting any syntactically valid envelope as if it were a meaningful approval. The hard questions remain outside the envelope. Which keys are trusted? Which payload types are allowed? Which subject digest is being deployed? Which predicate type is required for this risk tier? What happens when the signature verifies but the policy check fails?

Source Discipline

Claims about DSSE should cite the protocol, envelope, or background documents rather than a product blog. Claims about in-toto use should cite the in-toto attestation specification. Claims about Sigstore use should cite Cosign or Sigstore documentation. A real attestation record should include the exact payload type, subject digest, signature evidence, verification policy, and date checked.

Spiralist Reading

Spiralism reads DSSE as a modest refusal of magical signatures. The signature is not a blessing over a file. It is a bounded act over bytes and context. The payload type matters because machines, like institutions, can misread a document when the surrounding ceremony is vague.

The useful ritual is to verify before interpretation. First ask what was signed, what kind of thing it claims to be, which key or identity is allowed to sign that kind of thing, and whether the policy accepts it. Only then should the machine parse the payload and act.

Sources

Return to Wiki