Client aborts on root key rotation when either the old key set or new key set has an unmet threshold

[heartsucker]

This was partially covered by #32, but I don't think the current test case is good enough.

TODO

Case 1:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 4, 5, 6
• 2.root.json is signed with 1, 2, 4, 5, 6
• client aborts

Case 2:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 4, 5, 6
• 2.root.json is signed with 1, 2, 3, 5, 6
• client aborts

Case 3:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 1, 2, and 4
• 2.root.json is signed with 1, 2, 3
• client aborts

Case 4:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 1, 2, and 4
• 2.root.json is signed with 1, 2, 4
• client aborts

Case 5:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 2 and keys 3, 4, and 5
• 2.root.json is signed with 1, 2, 3, 4, 5
• client continues

[heartsucker]

@trishankkarthik Can you let me know if my interpretation of the spec is correct with these test cases?

[heartsucker]

Upstream issue for test cases: advancedtelematic/tuf-test-vectors#38

[vladimir-v-diaz]

The indicated client behaviour for all these test cases seems correct to me!

The root file must be signed by a threshold of keys for both the current and previous versions.

1.root.json = keys A, B, C
2.root.json = keys D, E, F; threshold = 3

2.root.json must be signed by keys A, B, C, D, E, F

Root must include a threshold of signatures for the previous version so that clients with the previous version of Root can validate it, and clients with access to only the current version must be able to validate it on its own (so it must be signed with a threshold of currently trusted keys).

[heartsucker]

@vladimir-v-diaz Great, thanks :D

[heartsucker]

@vladimir-v-diaz Wait, follow up actually. To clear up some ambiguity in the spec, it sounds like 2.root.json can specify a threshold of 1 and have only 1 key from 1.root.json sign it even if 1.root.json has a threshold of 3. I think the spec should clarify that this is not the case.

[vladimir-v-diaz]

Good point! The specification probably does not clarify that this is not the case.

[awwad]

Yeah, if that's not clear in the spec, it certainly should be. At a high level, the rules for validating new metadata files come exclusively from already-validated metadata files. We don't care what the new file's threshold is when we're validating that new file.

(Caveat: you might additionally expect the new file's signature to be valid per the new file, but this must come only after it is validated per rules from the old, trusted file.)