Adding scenario for tag to digest mapping

[sudo-bmitch]

This covers the scenario where a tag could be modified to point to a vulnerable but previously signed digest. Example attacks I can think of:

• Change x-scratch to point to the digest used by x-alpine to include a shell that may expose vulnerabilities.
• If v3 is updated after a CVE is discovered, an attacker could roll back the tag to point to the vulnerable digest.

The end goal is when users pull image:tag, the returned digest can be verified as one the image signer has currently approved for tag. By including this use case, we also cover the use case supported by Notary v1.

Signed-off-by: Brandon Mitchell [email protected]

[dlorenc]

Maybe a more accurate name for this would be "signing a tag-> digest mapping"? It sounds like you're not proposing we sign tags themselves, but rather the mapping of a tag to a digest at a particular moment in time.

[dlorenc]

Thanks!

[SteveLasker]

This is goodness as it captures the root problem of tag rollbacks, without implying the solution.
It also doesn't suggest the older digest is invalid. It just implies we need a solution that says tag:v1 that updated from digest:a to digest:b must accurately reflect the current digest of tag:v1