# Cross Registry Image Signing

As developers and customers alike move to containers as the [common unit of deployment](https://stevelasker.blog/2016/05/26/docker-containers-as-the-new-binaries-of-deployment/), users want to know the images are the "official" images that were initially published.

Docker has provided Content Trust as baseline solution. Content Trust signs the manifest of an image, which can be verified before execution.

While this provides the basic scenario, customers are struggling with Moving an image from one registry, or repo, to another invalidates the signature

## Moving Images Across Registries

Software vendors, and hubs will provide official sources of software. Docker, Microsoft, Red Hat, Oracle are just a few of the current public registry offerings. Regardless of where an image originates from, a typical [best practice](https://stevelasker.blog/2018/11/14/choosing-a-docker-container-registry/) involves copying the image into the customers private registry. Or, they use official base images whose layers are pushed to their private registry.
With the current content-trust, notary implementation, there's no means to validate the copied images, or layers are the official originals.

## Copying the SSL/HTTPS Model

For an equivalent level of usability and security, we can compare the experience users have when browsing websites, or using SSL based connections.

1. A user navigates to a website, using https://
1. The site has an SSL key from some issuing authority
1. The browser validates the certificate and presents a secure key icon to the user, validating they're securely browsing

## Cross Registry Image Signing Requirements

1. A developer can sign an image, independent of the registry it's pushed to
1. A user can pull an image from a registry, push it to another registry and/or repo, and the signature is maintained.

## Certificate Validation Independent of the Registry

To provide the ease of use for the masses, with the needs of the larger software companies, certificates can be acquired via multiple channels.

- Registry services, like Docker Hub, acr, ecr, gcr, Quay.io can offer certificates for ease of use. These would be stored in their Notary service. While the certificate may be issued by a registry provider, the certificate has no affinity to the registry. The image can be pulled/pushed to other registries
- Larger software companies, like Microsoft, Adobe, Oracle, IBM/Red Hat may have one or more root certificates they manage, and host their own Notary service.

## Federated Notary

As images are moved between registries, the embedded certificates within the image would reference it's original notary service. Registries may opt into federating notary, allowing the metadata/content to move with the image.
This would provide better isolation and resiliency as the new hosting registry could operate independently of the original notary.

**TODO: clarify this a bit. Add an picture of the workflow**

## Multiple Signatures

**TODO: add explination of multiple signatures for Dev, Staging, Scanning Validation, Prod...**