https://github.com/secure-systems-lab/dsse
A specification for signing methods and formats used by Secure Systems Lab projects.
https://github.com/secure-systems-lab/dsse
Last synced: 18 days ago
JSON representation
A specification for signing methods and formats used by Secure Systems Lab projects.
- Host: GitHub
- URL: https://github.com/secure-systems-lab/dsse
- Owner: secure-systems-lab
- License: apache-2.0
- Created: 2020-09-01T10:20:42.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2025-11-10T14:14:17.000Z (3 months ago)
- Last Synced: 2025-11-10T16:13:43.184Z (3 months ago)
- Language: Jupyter Notebook
- Homepage: https://dsse.dev
- Size: 119 KB
- Stars: 87
- Watchers: 18
- Forks: 21
- Open Issues: 19
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Maintainers: MAINTAINERS.md
Awesome Lists containing this project
- dereks-awesome-list - DSSE - Simple, foolproof standard for signing arbitrary data. (Security / Software Supply Chain Security)
README
# 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](background.md) for more information, including design
considerations and rationale.
## What is it?
Specifications for:
* [Protocol](protocol.md) (*required*)
* [Data structure](envelope.md), a.k.a. "Envelope" (*recommended*)
* (pending #9) Suggested crypto primitives
Out of scope (for now at least):
* Key management / PKI /
[exclusive ownership](https://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf)
## Why not...?
* Why not raw signatures? Too fragile.
* Why not [JWS](https://tools.ietf.org/html/rfc7515)? Too many insecure
implementations and features.
* Why not [PASETO](https://paseto.io)? JSON-specific, too opinionated.
* Why not the legacy TUF/in-toto signature scheme? JSON-specific, relies on
canonicalization.
See [Background](background.md) for further motivation.
## Who uses it?
* [in-toto](https://in-toto.io) (as described in [ITE-5](https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc), [go](https://github.com/in-toto/go-witness/tree/main/dsse), [python](https://github.com/in-toto/in-toto/blob/d8fa07f5c3c3e052319b1a9b0c06408cdf5b5185/in_toto/common_args.py#L170))
* [TUF](https://theupdateframework.io) (pending implementation of [TAP-17](https://github.com/theupdateframework/taps/pull/138))
* [gittuf](https://gittuf.dev) (implemented with extensions in [go](https://github.com/gittuf/gittuf/tree/main/internal/third_party/go-securesystemslib/dsse))
* [Sigstore](https://sigstore.dev) supports DSSE as an [entry type](https://github.com/sigstore/rekor-tiles/blob/main/api/proto/rekor/v2/dsse.proto) in Rekor, Sigstore's transparency log
* [Chainguard Images](https://www.chainguard.dev/unchained/reproducing-chainguards-reproducible-image-builds) use sigstore and in-toto (see above), and support DSSE
* [GUAC](https://guac.sh/) [supports DSSE entries](https://github.com/guacsec/guac/blob/main/pkg/ingestor/parser/dsse/parser_dsse.go) as a data type
* [JFrog](https://jfrog.com/) has a [free DSSE Attestation Online Decoder Tool](https://dsse.io/)
## How can we use it?
* There is a Python implementation in [this repository](implementation/).
* There's a DSSE library for Go in [go-securesystemslib](https://github.com/secure-systems-lab/go-securesystemslib/tree/main/dsse).
* Sigstore includes a [Go implementation](https://github.com/sigstore/sigstore/tree/main/pkg/signature/dsse)
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.