DSSE: Dead Simple Signing Envelope

Simple, foolproof standard for signing arbitrary data.

Features

• Supports arbitrary message encodings, not just JSON.
• Authenticates the message and the type to avoid confusion attacks.
• Avoids canonicalization to reduce attack surface.
• Allows any desired crypto primitives or libraries.

See Background for more information, including design considerations and rationale.

What is it?

Specifications for:

• Protocol (required)
• Data structure, a.k.a. "Envelope" (recommended)
• (pending #9) Suggested crypto primitives

Out of scope (for now at least):

• Key management / PKI / exclusive ownership

Why not...?

• Why not raw signatures? Too fragile.
• Why not JWS? Too many insecure implementations and features.
• Why not PASETO? JSON-specific, too opinionated.
• Why not the legacy TUF/in-toto signature scheme? JSON-specific, relies on canonicalization.

See Background for further motivation.

Who uses it?

• in-toto (as described in ITE-5, go, python)
• TUF (pending implementation of TAP-17)
• gittuf (implemented with extensions in go)
• Sigstore supports DSSE as an entry type in Rekor, Sigstore's transparency log
• Chainguard Images use sigstore and in-toto (see above), and support DSSE
• GUAC supports DSSE entries as a data type
• OpenClaw is adopting DSSE for signing and verifying hosted skill and plugin feeds (implementation)
• JFrog has a free DSSE Attestation Online Decoder Tool

How can we use it?

• There is a Python implementation in this repository.
• There's a DSSE library for Go in go-securesystemslib.
• Sigstore includes a Go implementation that supports hardware tokens, cloud KMS systems, and more.

Versioning

The DSSE specification follows semantic versioning, and is released using Git tags. The master branch points to the latest release. Changes to the specification are submitted against the devel branch, and are merged into master when they are ready to be released.

Governance & Licensing

• Scope
• Notices
• License
• Governance