How to perform modifications on bins handled by succinct hash bin delegations?

[MVrachev]

Description of issue or feature request:
Currently, I am working to support succinct hash bin delegation as described in TAP 15 in Repository Editor for TUF.
Repository Editor for Tuf is a CLI tool that tests the usability of the public API calls provided by python-tuf while also providing a good hands-on visualization approach to learn about python-tuf and the TUF specification as a whole.

While working on it I came up with the following question:
how do we want to approach changes related to delegated bins represented by succinct_roles dictionary inside a targets role?

For example, what should we do when a user wants to do the following in a bin metadata file:

1. add/remove a new key
2. change threshold
3. bump expiry
4. add/remove a target
5. add/remove/edit delegation
6. bump version

I want to discuss it with everyone who is interested but will especially love to hear the opinions of the maintainers.

[MVrachev]

Currently, I think that:

• changes 1 and 2 can currently be made with Targets API calls

  python-tuf/tuf/api/metadata.py

  Line 1980 in b5e952c

  def add_key(self, key: Key, role: Optional[str] = None) -> None:

  and

  python-tuf/tuf/api/metadata.py

  Line 2012 in b5e952c

  def revoke_key(self, keyid: str, role: Optional[str] = None) -> None:

  
  What probably is missing and can be a repository feature is resigning all of the bins and adding the corresponding signatures to each of the bins.

• changes 3 to 6 all should be individually handled by the corresponding bin without the need to do anything to the delegating metadata class containing the succinct_roles dict information.

What do the others think?
Do I have the right inituition?

[MVrachev]

@mnm678 and @lukpueh I am especially curious in hearing your opinions on the matter.

[mnm678]

Good question. I think that anything that is included in the succinct_roles definition should be changed with Targets API calls, like the ones you show above.

But something that only affects one bin (like adding a target) can be handled directly by that bin, just like a normal role adding a target.

[lukpueh]

Sounds right to me, and I would even say that, in terms of metadata update chains, there is nothing special about hash bin delegation when compared to any other delegation. This means whenever you change the keys or thresholds in delegating metadata (root or targets), you likely want to resign the delegated metadata, if you control the signing keys, which should always be true for hash bin delegation.

And you are right, 3 to 6 shouldn't affect the delegating role, but they do usually entail a chain of updates in snapshot and timestamp.

I left a similar comment a while ago in #958 (comment)

[jku]

Documenting the experiments on target adding and removal in repository-editor: https://github.com/vmware-labs/repository-editor-for-tuf/blob/main/tufrepo/librepo/repo.py#L131: both need a delegation search to be ergonomic (user should not need to know the exact bin role name to be able to add or remove a target) but interestingly the search can not be the same one in both cases

Expiry and version changes need to be automated anyway so the succinct delegation case isn't special.

Key changes should not have complications -- although the "succinct private key" might be useful to take into account when looking at key management: it's a single key that signs potentially tens of thousands of roles. repository-editor currently brute forces this with a tufrepo sign --all-targets which tries to sign all targets that it has keys for. This is obviously "a bit" inefficient.