Notary
By Docker/CNCF
Notary is a content trust and signing tool that lets publishers cryptographically sign container images and other content so consumers can verify authenticity and integrity before pulling or running them. Originally developed to power…
Definition
Notary is a content trust and signing tool that lets publishers cryptographically sign container images and other content so consumers can verify authenticity and integrity before pulling or running them. Originally developed to power Docker Content Trust, Notary implements the TUF (The Update Framework) specification for secure software update distribution, using a hierarchy of signing keys to protect against key compromise and stale or replayed content.
Overview
Before content signing tools like Notary existed, pulling a container image from a registry offered no built-in guarantee that the image was actually published by the party it claimed to be from, or that it hadn't been swapped for a tampered version between publishing and pulling. Notary was built to close that gap by implementing a structured trust model publishers and consumers could rely on without each side needing to invent its own signing convention. Mechanically, Notary is based on TUF, a specification designed originally for securing software update systems against a range of attacks, including key compromise, rollback to an older vulnerable version, and mix-and-match attacks where an attacker combines legitimate signed metadata in unintended ways. Notary organizes signing responsibility across a hierarchy of key roles, typically including a root key kept highly protected offline, and delegated keys used for routine signing of specific content, so that compromising a lower-level signing key doesn't compromise the entire trust chain. When Docker Content Trust is enabled, a client pulling an image verifies its signature chain against this hierarchy before allowing the pull to proceed. Notary predates the Sigstore project and represents an earlier approach to the same underlying problem: establishing verifiable publisher identity and content integrity for distributed artifacts. Where Sigstore's Cosign emphasizes keyless signing tied to ephemeral OIDC-based certificates and a public transparency log, Notary's TUF-based model relies on a more traditional, self-managed key hierarchy, which gives an organization full control but places the burden of key management squarely on the publisher. In practice, Notary has been used primarily through Docker Content Trust, where organizations that need to guarantee image provenance for internal registries enable signing so that only cryptographically verified images can be pulled and run. Notary itself is also usable as a standalone trust service for other kinds of content distribution that need the same rollback- and replay-resistant guarantees TUF provides, beyond just container images. Notary's key hierarchy model, while robust, requires real operational discipline: root keys must be stored securely and rarely used, delegated keys need rotation policies, and losing a root key can be a serious recovery problem. Partly because of this operational overhead and the rise of simpler keyless alternatives, much of the container ecosystem's newer signing activity has shifted toward Sigstore-based tooling, though Notary and TUF's underlying design principles remain influential and still see use, including in later Notary v2 and OCI-aligned signing efforts.
Key Features
- Implements the TUF specification for secure content signing and distribution
- Organizes signing keys into a hierarchy to limit blast radius of key compromise
- Protects against rollback and replay attacks on distributed content
- Originally powered Docker Content Trust for verified image pulls
- Separates root keys, kept offline, from routine delegated signing keys
- Provides a trust model usable beyond just container images
- Predates and differs from Sigstore's keyless, transparency-log-based model
- Open governance historically tied to Docker and CNCF-adjacent efforts