Metadata API: (maybe) Enforce public key content uniqueness in keys

Root and targets have a keys dictionary with keyid as key. It would be nice to know for sure that these keys are actually unique keys (and not e.g. the same key content with two different keyids).

One solution would be to validate that the keyid is correct according to spec:

KEYID: … a hexdigest of the SHA-256 hash of the canonical form of the key.

Having looked at the securesystemslib implementation I don’t think we can consider keyid reproducible… what SSLib considers canonical form depends on the settings that were used on the machine that generated the key, and those settings are not stored on the key itself.

The other solution would be to validate key content uniqueness in the keys dict ourselves. This might make sense: we could just not accept a keys dictionary that contained two keys with identical key content – I don’t think there’s a non-malicious, non-error case where that would happen.

[jku]

We want to warn the user on accidental duplicating keys, but do we want to stop the execution with an exception?

Maybe yes?

• it would prevent a repository tool from creating broken metadata
• it would prevent a client from being in a situation where signatures refers to a key that exists (in the file) and does not exist (in deserialized keys) at the same time

[jku]

Thanks. So to recap:

• we could check for key content uniqueness
• it would be a minor usability/sanitycheck feature, to prevent accidentally using the same key with two keyids
• it would not prevent maliciously using the same key in two forms (but if attacker is able to define the key content, they are typically also able to e.g. change thresholds or add new keys so this is not a huge issue)