45fa0f8
% container-signature(5) Container signature format
45fa0f8
% Miloslav Trmač
45fa0f8
% March 2017
45fa0f8
45fa0f8
# Container signature format
45fa0f8
45fa0f8
This document describes the format of container signatures,
45fa0f8
as implemented by the `github.com/containers/image/signature` package.
45fa0f8
45fa0f8
Most users should be able to consume these signatures by using the `github.com/containers/image/signature` package
45fa0f8
(preferably through the higher-level `signature.PolicyContext` interface)
45fa0f8
without having to care about the details of the format described below.
45fa0f8
This documentation exists primarily for maintainers of the package
45fa0f8
and to allow independent reimplementations.
45fa0f8
45fa0f8
## High-level overview
45fa0f8
45fa0f8
The signature provides an end-to-end authenticated claim that a container image
45fa0f8
has been approved by a specific party (e.g. the creator of the image as their work,
45fa0f8
an automated build system as a result of an automated build,
45fa0f8
a company IT department approving the image for production) under a specified _identity_
45fa0f8
(e.g. an OS base image / specific application, with a specific version).
45fa0f8
45fa0f8
A container signature consists of a cryptographic signature which identifies
45fa0f8
and authenticates who signed the image, and carries as a signed payload a JSON document.
45fa0f8
The JSON document identifies the image being signed, claims a specific identity of the
45fa0f8
image and if applicable, contains other information about the image.
45fa0f8
45fa0f8
The signatures do not modify the container image (the layers, configuration, manifest, …);
45fa0f8
e.g. their presence does not change the manifest digest used to identify the image in
45fa0f8
docker/distribution servers; rather, the signatures are associated with an immutable image.
45fa0f8
An image can have any number of signatures so signature distribution systems SHOULD support
45fa0f8
associating more than one signature with an image.
45fa0f8
45fa0f8
## The cryptographic signature
45fa0f8
45fa0f8
As distributed, the container signature is a blob which contains a cryptographic signature
45fa0f8
in an industry-standard format, carrying a signed JSON payload (i.e. the blob contains both the
45fa0f8
JSON document and a signature of the JSON document; it is not a “detached signature” with
45fa0f8
independent blobs containing the JSON document and a cryptographic signature).
45fa0f8
45fa0f8
Currently the only defined cryptographic signature format is an OpenPGP signature (RFC 4880),
45fa0f8
but others may be added in the future.  (The blob does not contain metadata identifying the
45fa0f8
cryptographic signature format. It is expected that most formats are sufficiently self-describing
45fa0f8
that this is not necessary and the configured expected public key provides another indication
45fa0f8
of the expected cryptographic signature format. Such metadata may be added in the future for
45fa0f8
newly added cryptographic signature formats, if necessary.)
45fa0f8
45fa0f8
Consumers of container signatures SHOULD verify the cryptographic signature
45fa0f8
against one or more trusted public keys
45fa0f8
(e.g. defined in a [policy.json signature verification policy file](policy.json.md))
45fa0f8
before parsing or processing the JSON payload in _any_ way,
45fa0f8
in particular they SHOULD stop processing the container signature
45fa0f8
if the cryptographic signature verification fails, without even starting to process the JSON payload.
45fa0f8
45fa0f8
(Consumers MAY extract identification of the signing key and other metadata from the cryptographic signature,
45fa0f8
and the JSON payload, without verifying the signature, if the purpose is to allow managing the signature blobs,
45fa0f8
e.g. to list the authors and image identities of signatures associated with a single container image;
45fa0f8
if so, they SHOULD design the output of such processing to minimize the risk of users considering the output trusted
45fa0f8
or in any way usable for making policy decisions about the image.)
45fa0f8
45fa0f8
### OpenPGP signature verification
45fa0f8
45fa0f8
When verifying a cryptographic signature in the OpenPGP format,
45fa0f8
the consumer MUST verify at least the following aspects of the signature
45fa0f8
(like the `github.com/containers/image/signature` package does):
45fa0f8
45fa0f8
- The blob MUST be a “Signed Message” as defined RFC 4880 section 11.3.
45fa0f8
  (e.g. it MUST NOT be an unsigned “Literal Message”, or any other non-signature format).
45fa0f8
- The signature MUST have been made by an expected key trusted for the purpose (and the specific container image).
45fa0f8
- The signature MUST be correctly formed and pass the cryptographic validation.
45fa0f8
- The signature MUST correctly authenticate the included JSON payload
45fa0f8
  (in particular, the parsing of the JSON payload MUST NOT start before the complete payload has been cryptographically authenticated).
45fa0f8
- The signature MUST NOT be expired.
45fa0f8
45fa0f8
The consumer SHOULD have tests for its verification code which verify that signatures failing any of the above are rejected.
45fa0f8
45fa0f8
## JSON processing and forward compatibility
45fa0f8
45fa0f8
The payload of the cryptographic signature is a JSON document (RFC 7159).
45fa0f8
Consumers SHOULD parse it very strictly,
45fa0f8
refusing any signature which violates the expected format (e.g. missing members, incorrect member types)
45fa0f8
or can be interpreted ambiguously (e.g. a duplicated member in a JSON object).
45fa0f8
45fa0f8
Any violations of the JSON format or of other requirements in this document MAY be accepted if the JSON document can be recognized
45fa0f8
to have been created by a known-incorrect implementation (see [`optional.creator`](#optionalcreator) below)
45fa0f8
and if the semantics of the invalid document, as created by such an implementation, is clear.
45fa0f8
45fa0f8
The top-level value of the JSON document MUST be a JSON object with exactly two members, `critical` and `optional`,
45fa0f8
each a JSON object.
45fa0f8
45fa0f8
The `critical` object MUST contain a `type` member identifying the document as a container signature
45fa0f8
(as defined [below](#criticaltype))
45fa0f8
and signature consumers MUST reject signatures which do not have this member or in which this member does not have the expected value.
45fa0f8
45fa0f8
To ensure forward compatibility (allowing older signature consumers to correctly
45fa0f8
accept or reject signatures created at a later date, with possible extensions to this format),
45fa0f8
consumers MUST reject the signature if the `critical` object, or _any_ of its subobjects,
45fa0f8
contain _any_ member or data value which is unrecognized, unsupported, invalid, or in any other way unexpected.
45fa0f8
At a minimum, this includes unrecognized members in a JSON object, or incorrect types of expected members.
45fa0f8
45fa0f8
For the same reason, consumers SHOULD accept any members with unrecognized names in the `optional` object,
45fa0f8
and MAY accept signatures where the object member is recognized but unsupported, or the value of the member is unsupported.
45fa0f8
Consumers still SHOULD reject signatures where a member of an `optional` object is supported but the value is recognized as invalid.
45fa0f8
45fa0f8
## JSON data format
45fa0f8
45fa0f8
An example of the full format follows, with detailed description below.
45fa0f8
To reiterate, consumers of the signature SHOULD perform successful cryptographic verification,
45fa0f8
and MUST reject unexpected data in the `critical` object, or in the top-level object, as described above.
45fa0f8
45fa0f8
```json
45fa0f8
{
45fa0f8
    "critical": {
45fa0f8
        "type": "atomic container signature",
45fa0f8
        "image": {
45fa0f8
            "docker-manifest-digest": "sha256:817a12c32a39bbe394944ba49de563e085f1d3c5266eb8e9723256bc4448680e"
45fa0f8
        },
45fa0f8
        "identity": {
45fa0f8
            "docker-reference": "docker.io/library/busybox:latest"
45fa0f8
        }
45fa0f8
    },
45fa0f8
    "optional": {
45fa0f8
        "creator": "some software package v1.0.1-35",
45fa0f8
        "timestamp": 1483228800,
45fa0f8
    }
45fa0f8
}
45fa0f8
```
45fa0f8
45fa0f8
### `critical`
45fa0f8
45fa0f8
This MUST be a JSON object which contains data critical to correctly evaluating the validity of a signature.
45fa0f8
45fa0f8
Consumers MUST reject any signature where the `critical` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
45fa0f8
45fa0f8
### `critical.type`
45fa0f8
45fa0f8
This MUST be a string with a string value exactly equal to `atomic container signature` (three words, including the spaces).
45fa0f8
45fa0f8
Signature consumers MUST reject signatures which do not have this member or this member does not have exactly the expected value.
45fa0f8
45fa0f8
(The consumers MAY support signatures with a different value of the `type` member, if any is defined in the future;
45fa0f8
if so, the rest of the JSON document is interpreted according to rules defining that value of `critical.type`,
45fa0f8
not by this document.)
45fa0f8
45fa0f8
### `critical.image`
45fa0f8
45fa0f8
This MUST be a JSON object which identifies the container image this signature applies to.
45fa0f8
45fa0f8
Consumers MUST reject any signature where the `critical.image` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
45fa0f8
45fa0f8
(Currently only the `docker-manifest-digest` way of identifying a container image is defined;
45fa0f8
alternatives to this may be defined in the future,
45fa0f8
but existing consumers are required to reject signatures which use formats they do not support.)
45fa0f8
45fa0f8
### `critical.image.docker-manifest-digest`
45fa0f8
45fa0f8
This MUST be a JSON string, in the `github.com/opencontainers/go-digest.Digest` string format.
45fa0f8
45fa0f8
The value of this member MUST match the manifest of the signed container image, as implemented in the docker/distribution manifest addressing system.
45fa0f8
45fa0f8
The consumer of the signature SHOULD verify the manifest digest against a fully verified signature before processing the contents of the image manifest in any other way
45fa0f8
(e.g. parsing the manifest further or downloading layers of the image).
45fa0f8
45fa0f8
Implementation notes:
45fa0f8
* A single container image manifest may have several valid manifest digest values, using different algorithms.
45fa0f8
* For “signed” [docker/distribution schema 1](https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-1.md) manifests,
45fa0f8
the manifest digest applies to the payload of the JSON web signature, not to the raw manifest blob.
45fa0f8
45fa0f8
### `critical.identity`
45fa0f8
45fa0f8
This MUST be a JSON object which identifies the claimed identity of the image (usually the purpose of the image, or the application, along with a version information),
45fa0f8
as asserted by the author of the signature.
45fa0f8
45fa0f8
Consumers MUST reject any signature where the `critical.identity` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
45fa0f8
45fa0f8
(Currently only the `docker-reference` way of claiming an image identity/purpose is defined;
45fa0f8
alternatives to this may be defined in the future,
45fa0f8
but existing consumers are required to reject signatures which use formats they do not support.)
45fa0f8
45fa0f8
### `critical.identity.docker-reference`
45fa0f8
45fa0f8
This MUST be a JSON string, in the `github.com/docker/distribution/reference` string format,
45fa0f8
and using the same normalization semantics (where e.g. `busybox:latest` is equivalent to `docker.io/library/busybox:latest`).
45fa0f8
If the normalization semantics allows multiple string representations of the claimed identity with equivalent meaning,
45fa0f8
the `critical.identity.docker-reference` member SHOULD use the fully explicit form (including the full host name and namespaces).
45fa0f8
45fa0f8
The value of this member MUST match the image identity/purpose expected by the consumer of the image signature and the image
45fa0f8
(again, accounting for the `docker/distribution/reference` normalization semantics).
45fa0f8
45fa0f8
In the most common case, this means that the `critical.identity.docker-reference` value must be equal to the docker/distribution reference used to refer to or download the image.
45fa0f8
However, depending on the specific application, users or system administrators may accept less specific matches
45fa0f8
(e.g. ignoring the tag value in the signature when pulling the `:latest` tag or when referencing an image by digest),
45fa0f8
or they may require `critical.identity.docker-reference` values with a completely different namespace to the reference used to refer to/download the image
45fa0f8
(e.g. requiring a `critical.identity.docker-reference` value which identifies the image as coming from a supplier when fetching it from a company-internal mirror of approved images).
45fa0f8
The software performing this verification SHOULD allow the users to define such a policy using the [policy.json signature verification policy file format](policy.json.md).
45fa0f8
45fa0f8
The `critical.identity.docker-reference` value SHOULD contain either a tag or digest;
45fa0f8
in most cases, it SHOULD use a tag rather than a digest.  (See also the default [`matchRepoDigestOrExact` matching semantics in `policy.json`](policy.json.md#signedby).)
45fa0f8
45fa0f8
### `optional`
45fa0f8
45fa0f8
This MUST be a JSON object.
45fa0f8
45fa0f8
Consumers SHOULD accept any members with unrecognized names in the `optional` object,
45fa0f8
and MAY accept a signature where the object member is recognized but unsupported, or the value of the member is valid but unsupported.
45fa0f8
Consumers still SHOULD reject any signature where a member of an `optional` object is supported but the value is recognized as invalid.
45fa0f8
45fa0f8
### `optional.creator`
45fa0f8
45fa0f8
If present, this MUST be a JSON string, identifying the name and version of the software which has created the signature.
45fa0f8
45fa0f8
The contents of this string is not defined in detail; however each implementation creating container signatures:
45fa0f8
45fa0f8
- SHOULD define the contents to unambiguously define the software in practice (e.g. it SHOULD contain the name of the software, not only the version number)
45fa0f8
- SHOULD use a build and versioning process which ensures that the contents of this string (e.g. an included version number)
45fa0f8
  changes whenever the format or semantics of the generated signature changes in any way;
45fa0f8
  it SHOULD not be possible for two implementations which use a different format or semantics to have the same `optional.creator` value
45fa0f8
- SHOULD use a format which is reasonably easy to parse in software (perhaps using a regexp),
45fa0f8
  and which makes it easy enough to recognize a range of versions of a specific implementation
45fa0f8
  (e.g. the version of the implementation SHOULD NOT be only a git hash, because they don’t have an easily defined ordering;
45fa0f8
  the string should contain a version number, or at least a date of the commit).
45fa0f8
45fa0f8
Consumers of container signatures MAY recognize specific values or sets of values of `optional.creator`
45fa0f8
(perhaps augmented with `optional.timestamp`),
45fa0f8
and MAY change their processing of the signature based on these values
45fa0f8
(usually to acommodate violations of this specification in past versions of the signing software which cannot be fixed retroactively),
45fa0f8
as long as the semantics of the invalid document, as created by such an implementation, is clear.
45fa0f8
45fa0f8
If consumers of signatures do change their behavior based on the `optional.creator` value,
45fa0f8
they SHOULD take care that the way they process the signatures is not inconsistent with
45fa0f8
strictly validating signature consumers.
45fa0f8
(I.e. it is acceptable for a consumer to accept a signature based on a specific `optional.creator` value
45fa0f8
if other implementations would completely reject the signature,
45fa0f8
but it would be very undesirable for the two kinds of implementations to accept the signature in different
45fa0f8
and inconsistent situations.)
45fa0f8
45fa0f8
### `optional.timestamp`
45fa0f8
45fa0f8
If present, this MUST be a JSON number, which is representable as a 64-bit integer, and identifies the time when the signature was created
45fa0f8
as the number of seconds since the UNIX epoch (Jan 1 1970 00:00 UTC).