Prevent promiscuous delegations from violating security

Summary

Items 4.5.1-4.5.9 in the Detailed Workflows section (5.1) of the specification do not instruct the implementer in how to "process" the delegated role files, and there are tempting dangers here that must be averted.

Details

Consider this scenario (again... I know...):

• Targets delegates /a/\* to A
• Targets delegates /b/\* to B
• A delegates /a/\* to C, expecting threshold 1, key kA
• B delegates /b/\* to C, expecting threshold 1, key kB
• Targets, A, and B, are signed by all expected keys.
• C is signed by kA, but not by kB

Now, the client:

• updates top-level metadata, retrieving Root, Timestamp, Snapshot, and Targets.
• tries to get target info for target /a/foo.txt.
  • gets A.json
  • validates A.json based on the delegation info in Targets.json: valid
  • gets C.json
  • validates C.json based on the delegation info in A.json: valid, C.json was correctly signed by kA ((this step is not quite clear in the spec in 5.1:4.5.1+, but certainly implied))
• tries to get target info for target /b/bar.txt
  • gets B.json
  • validates B.json based on the delegation info in Targets.json: valid
  • regardless of whether or not C.json is cached, or whether we know that C.json has previously been validated (on a different delegation pathway, seeking a different target), MUST perform validation again, making sure that C.json was correctly signed by kB (and not just kA, as we validated before).

At that last step, it is likely that the client has cached C.json, kept it in a way that signals that it has been validated, in much the way that the top-level roles should be kept if and only if they are validated. The prior validation expecting kA cannot be allowed to pre-empt the validation expecting kB. This should probably be clear in the spec, as it is probably too easy to fail to catch. It requires that the implementer carefully consider the implications of promiscuous delegations.

Fix

A possible fix is to consider adding, between the 2nd and 3rd sentences in 5.1:4.5.1 in the spec, something like "Check the signature on the delegated role file to make sure that it satisfies the requirements (threshold, keys, etc.) of the delegation that brought us to it." A little more rearrangement might be better, but this would probably work.

Read tuf-spec.md, especially the Detailed Workflows section 5.1 and items 4.5.1–4.5.9. Review how delegated role files are processed and how cached metadata is treated, then update the specification so each role is validated against the delegation that led to it, including threshold and key requirements. Done means the promiscuous-delegation scenario is unambiguous in the workflow.