Loosen the keyid verification requirement?

WRT keyids, we currently say this:

4.2. File formats: general principles
KEYID: The identifier of the key signing the ROLE object, which is a hexdigest of the SHA-256 hash of the canonical form of the key.

4.3. File formats: root.json
KEYID: A KEYID, which MUST be correct for the specified KEY. Clients MUST calculate each KEYID to verify this is correct for the associated key`

I believe there is a consensus that these requirements are not useful and are even harmful:

• the client calculation requirement is not beneficial to security
• the client calculation requirement makes clients more complicated
• maintaining repositories is more difficult: if the key json changes in ways that does not change the PEM, that demands a keyid change which then means all the delegations and signatures with this keyid need to change

There is a TAP https://github.com/theupdateframework/taps/blob/master/tap12.md to change this but as it reaches quite far it has not been merged to the spec yet.

proposal

In preparation for tap 12 could we just modify the language slightly so that

• repositories SHOULD set the keyid as before
• clients SHOULD NOT expect the keyid to to be anything expect a string that is unique within the keyid strings in that metadata

Both are "should" in order to keep compatibility with current implementations while guiding new implementations into the most useful functionality.

Start by reading tap12.md and the quoted sections 4.2 and 4.3 of the specification. Compare the proposed SHOULD language with the existing keyid requirements and determine the full set of affected specification text. Done means the requirements consistently allow unique keyid strings while preserving the stated compatibility guidance.