secure-systems-lab/dsse

A specification for signing methods and formats used by Secure Systems Lab projects.

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 (pending implementation of ITE-5)
• TUF (pending implementation of TAP-17)

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.