Discussion of TAP 13: User Selection of the Top-Level Target Files Through Mapping Metadata

[mnm678]

TAP 13 was introduced in #118.

There is a reference implementation available (built on the legacy python-tuf code) at theupdateframework/python-tuf#1103.

Open questions (from the pr discussion):

• repository vs client hosted alternate top-level targets metadata The TAP currently describes repository hosted metadata that is pointed to by the client, but this does not give the client as much control over the subset of packages on a repository that they trust. For example, a client may want to limit the use of a repository to 2 specific packages. In the current proposal they would need to upload new metadata that specifies these exact packages, which may not be possible if the repository is controlled by a third party. For this reason, I think we should consider allowing the client to provide a mapping to a local top-level targets file.

• client mapping format This depends a bit on the above, but there are a couple of mapping formats described here and in the POC. One big question is whether this should be a part of the existing repository mapping metadata.

• metadata on multiple repositories How does this TAP interact with TAP 4? Specifically, does the targets mapping apply in the same way for every repository, or should a client be able to specify a different mapping for each repository. It would give the client more flexibility if they could set different mappings for each repository, though this may require a larger change to the repository mapping metadata.

[joshuagl]

Some thoughts on these questions:

• repository vs client hosted alternate top-level targets metadata I like the suggestion to allow a client to provide a mapping to a local top-level targets metadata – is that a new, follow-on, TAP or something we should figure out in the scope of this TAP?
• client mapping format Looking at the client mapping format used in the PoC I'd like to suggest "targets_filename" -> "targets_rolename" as we want to move away from being file-centric in the spec. Otherwise, that mapping format seems like a reasonable starting point.
• metadata on multiple repositories I suppose the naive approach here is that a TAP13 mapping lists trusted keys for a targets role (top-level or delegated) and that any targets metadata in a TAP4 targets mapping would need to be able to be verified with a threshold of the TAP13 provided keys for the targets role. I don't think there's a security issue here? Maybe some threshold counting gnarliness if keys are being reused?