Hi Brian,

Justin Cappos CC'd will have to answer on the precise ownership of the tuf repo. Answers to the other questions follow:

• What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
• Content (images) is considered to have a canonical name independent of where it is stored. Notary servers will happily service any names for which they are configured (generally this means they will service any name the requesting user can get a JWT for from the appropriate authorizing server for which notary holds a public cert). Containerd has been working recently to support this same model. A given notary server will serve consistent data for a given name, and one notary server can be used to service many image repositories. A key thing to note is that the name of the content must be consistent, this is because that name is included in the notary repository. This reduces the chance that notary data can be misused in the case that a key is reused across multiple repos. I'm happy to go in to more depth if that's interesting, it's just a long, complex explanation, and this is already a relatively verbose answer.
• Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
• Absolutely, this is one of the things the docker security team has been pushing in our secure software supply chain talks over the last year+
• The main benefit compared to just signing an image digest is revocation?
• Other significant benefits I would count as equal to revocation: freshness, delegation to alternate signers, painless key compromise recovery in many situations (this one I would put higher than revocation as a benefit).
• Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
• Not explicitly, it would be very short. TUF is a description of a minimal data structure and update process, Notary is a Golang implementation of that, and DCT is an integration of Notary in to docker (with some opinions on delegation priority and which keys are online vs offline)

If more explanation is needed I'm happy to provide it, or if I missed the mark on any of the answers, let me know.

Thanks,

David

On Mon, Jul 10, 2017 at 6:54 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote:

Follow-up questions on Notary:

• What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
• Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
  
• The main benefit compared to just signing an image digest is revocation?
• Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
• Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?

Thanks.

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc