Reconsider keyid "compliance"

Metadata API currently does not validate that keyid is a hex digest of the keys canonical form, we also do not test for this.

I maintain that this is fine from a security perspective: being able to calculate keyid from key value brings us no value that I can see, just more complicated code. See also https://github.com/theupdateframework/taps/blob/master/tap12.md

However, as shown in https://github.com/theupdateframework/go-tuf/pull/228 go-tuf client does seem to check that keyids are as specified and arguably they are spec compliant in doing so. So let’s reconsider: should we try to ensure that this creates keys with keyids that fulfill the requirements:

sslib_key = generate_ed25519_key()
key = Key.from_securesystemslib_key(sslib_key)

I assume that last call removes some unused fields from the key structure to make the metadata cleaner… and that probably makes the key not hash correctly.

[jku]

Right, so I suppose the result is then:

• there’s no standard definitition for canonical form of key. The form securesystemslib uses is a bit weird but there’s likely not much point in tweaking that
• consensus is that keyids should be freeform (generating a “unique” hash id by default is fine but keyids should still be 100% in control of whoever inserts them into delegating metadata): this is how metadata API already operates
• My original assumption that we did something differently in Metadata API does not seem correct: the securesystemslib method of keyid generation is described above and has been used for a long time
• We are not planning to change keyid handling in Metadata API: if a user wants to use their definition of “canonical form of key” to calculate a new keyid and use that instead of the default they are free to do so

Closing as WONTFIX

[lukpueh]

For reference: https://github.com/secure-systems-lab/securesystemslib/issues/308 summarizes securesystemslib/TUF/in-toto public key formats and points out issues/inconsistencies, such as the ambiguously defined “private” field you mention. It also suggests to “better decouple default keyids from keys, to allow the use of custom keyids, but with a canonical json computed keyid as fallback”