Correct and clarify "6.3.1 Updating targets metadata" for delegated targets roles

[ethan-lowman-dd]

Step three of 6.3.1 states:

Sign the updated targets metadata with at least a THRESHOLD of keys for the associated targets role (either the top-level targets role, or a delegated targets role).

For delegated targets roles, keys are associated with delegations (edges), not roles (nodes) in the delegation graph. The spec glosses over a lot of detail here. I think the intended meaning is that for each incoming delegation to a role, the metadata is signed for a threshold of the keys for that specific delegation edge. There is not necessarily just one threshold or one set of keys.

I see two choices: we could fix the spec for all these edge cases for strange delegation graphs (e.g. #177), or adjust the spec to explicitly state that delegation graphs must be trees (i.e. each targets role must have only one incoming delegation). I haven't heard of anyone using non-tree delegation graphs in practice, and supporting these use cases makes code more complex, and therefore probably less secure.

[lukpueh]

Also related:

• Prevent promiscuous delegations from violating security #19
• Roles and Delegations are still confused in parts of the implementation python-tuf#660
  -> this one discusses no longer relevant issues in legacy python-tuf code base, but also has some good general observations about roles vs. delegations

[hosseinsia]

+1000
Thanks Ethan for analysis. I think making it a tree is the right way to do this. Otherwise identify and key management would be a mess, and role-key relation for delegation diverges from what is for top-level.
Adding tree constraint to the delegations makes the life of developers and the users way easier.

[ethan-lowman-dd]

To clarify: the reason restricting the delegation graphs to trees helps with the edge vs. node ambiguity is that with a tree delegation structure, associating keys with edges (delegations) is equivalent to associating keys with nodes (roles). This is because in a tree, there is exactly one incoming edge to each node, except for the root (top level targets).

[JustinCappos]

It does make things more difficult in situations where a repository is shared by different users that want to delegate to each other. I'm not sure if PyPI, TAF, or others want this model, but we should consider this before making the change.

…

On Tue, Apr 5, 2022 at 2:22 AM Ethan Lowman ***@***.***> wrote: To clarify: the reason restricting the delegation graphs to trees helps with the edge vs. node ambiguity is that with a tree delegation structure, associating keys with edges (delegations) is equivalent to associating keys with nodes (roles). This is because in a tree, there is exactly one incoming edge to each node, except for the root (top level targets). — Reply to this email directly, view it on GitHub <#214 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD5QUUTDLPWOUQ5E4M3VDMXPTANCNFSM5R4JYR3A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>