[TAP 8] Simplify rotate file names

[mnm678]

Simplify rotate files per the discussion in the related issue.

[JustinCappos]

Needs some help / clarification in a few places...

[hannesm]

Thanks for this proposal. This indeed simplifies the proposal a lot.

Now, thinking about "why did we use a hash initially", as far as I remember:

• consider a setup where something is delegated to a team (i.e. a quorum of 2 from alice, bob, carla)
• how can this team modify its validity? (i.e. "we want a quorum of 3 from alice, bob, carla, doreen")

Would this still be possible with this simplification? From my memory, the reason to use a hash of the validity expression came from the observation that there's no distinct file for a delegation.

But I've neither followed up closely with TUF development, nor am I certain that the scenario described above is worth considering in your use cases. For me, there is the question "who is part of a team?" and "where are signatures put?" -- and I want to minimize the amount of files that have the requirement to have multiple signatures (since that means the file has to be passed to multiple entities before being put (and being valid) into the repository).

[mnm678]

Would this still be possible with this simplification? From my memory, the reason to use a hash of the validity expression came from the observation that there's no distinct file for a delegation.

Yes, the team could create a rotate file for the role with the next version number (so 1 to start). The goal here is to replicate the file name uniqueness from the hash with a version number. The rotate files are still signed with the previously trusted set of keys, and so only the existing team can create a valid rotate file.

[joshuagl]

I really like the simplification here, nice. I made one minor suggestion to clarify rotate file names, otherwise this looks great.

[JustinCappos]

This set of changes LGTM. Other PRs need to merge before this TAP can move forward.