Requirements: Artifact Signing about distribution-spec

[SteveLasker]

Adding links to Notary v2 efforts, and closing this issue as it's being tracked separatley:

• Notary v2 Requirements
• Notary v2 Scenarios
• Notary v2, Prototype-1

[wking]

An important design constraint is whether additional sigs can be added without changing the root image digest (i.e. what the mutable tag points to). If bumping tags is ok, sigs can live in CAS. If tags cannot be bumped, tags must live outside of CAS.

[wking]

Previous discussion in opencontainers/image-spec#22, opencontainers/image-spec#176, and opencontainers/image-spec#400.

[jtoberon]

An important design constraint is whether additional sigs can be added without changing the root image digest (i.e. what the mutable tag points to). If bumping tags is ok, sigs can live in CAS. If tags cannot be bumped, tags must live outside of CAS.

@wking Can you add more details to your note? When you say "can live in CAS," do you just mean within the manifest like in schema 1?

[wking]

When you say "can live in CAS," do you just mean within the manifest like in schema 1?

Manifests get pulled by reference, and references can be names or digest, so they're content addressable, but also tag-addressable (presumably to make space for HTTP content-negotiation for compat with clients who don't understand new media types). But now we have indexes, which are kind of tiptoeing into in-CAS content negotiation. By "in CAS" I mean "is pushed as an opaque blob and retrieved by digest", like we currently use for layers. It would be nice to be able to push whatever types you want (including signature objects) into the CAS blob store, and then push an array of descriptors as the mutable tag. Clients would request the tag by name, and the server would select an entry based on content negotiation Accept headers vs. the media types in the tag's descriptors. Then signed content looks like a GET /<repo-name>/tag/<tag-name> with Accept: some-signature-type, possibly with fallbacks in Accept to index, manifest, etc. types if you can accept unsigned content (e.g. because you're going to follow-up and verify the resulting digest with Notary or some other non-CAS signature store).

[vbatts]

i think this issue can be closed. This is the point of the Notary v2 discussion, and to store the signatures themselves as referenced blobs in a registry. Whether or not Notary v2 fully delivers on that is not a blocker for this distribution-spec.