Clients disagree on what to do with duplicate keyids

[jku]

We should test role keyids where two ids in the list are the same.

Unfortunately the embedded clients disagree on what to do currently:
#108

• python-tuf fails to deserialize delegating metadata because there are duplicate keyids
• go-tuf accepts the delegating metadata, and the delegated roles metadata (as long as threshold is reached)

Either decision seems fairly reasonable but it would be even better if they were consistent.

We should decide what to do here

• double check the spec: my read on it is that spec does not explicitly require keyids to be unique but the assumption is sort of there
• maybe file a spec issue?
• we could also accept either choice in the test suite -- and only fail the test if duplicate keyids are accepted and they can fool the threshold check (EDIT this is done in test_duplicate_keys_root())

[jku]

@rdimitrov @lukpueh any strong feelings here?

[lukpueh]

We should decide what to do here

• double check the spec: my read on it is that spec does not explicitly require keyids to be unique but the assumption is sort of there

Hm, a very vague assumption maybe. The closest thing might be this requirement, but I think it can still be fulfilled with duplicate keyids.

Clients MUST ensure that for any KEYID represented in this key list and in other files,
inly one unique key has that KEYID. 

There are a few (albeit ambiguous -- see theupdateframework/specification#308) notes about keyid uniqueness in the context of threshold computation, but they don't cover the keyid list either.

• maybe file a spec issue?

Sounds good. Even if we don't make unique keyids a requirement, we could at least point out the risk of duplicate keyids

• we could also accept either choice in the test suite -- and only fail the test if duplicate keyids are accepted and they can fool the threshold check (EDIT this is done in test_duplicate_keys_root())

Great idea. The threshold check is what we care about.