Loosen the keyid verification requirement?

[jku]

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.

[trishankatdatadog]

Sounds reasonable to me.

TAP 12 would allow an idea I have for "self-identifying" keys (esp. given your work generalising the SSLib keys backend): the keyID should specifically exactly where to find it and what it is.

Generally, a self-identifying key ID would look like:

scheme://fully-qualified-name:version@multihash

For example (here the key version is clearly encoded twice):

gcpkms://projects/python-tuf-kms/locations/global/keyRings/securesystemslib-tests/cryptoKeys/ecdsa-sha2-nistp256/cryptoKeyVersions/1:1@122041dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8

WDYT?

[jku]

I would like to keep this proposal as the minimal one: the last time this discussion happened the result was TAP 12 -- it's a fine TAP but it seems it is incompatible with current spec so is now in TAP limbo. I think there may be a spec change that:

• maybe is not strictly an "incompatible" spec change so could be merged
• but still leads to an improvement in practical compatibility

[joshuagl]

Thanks for the constructive proposal and kudos for coming up with an elegant solution. +1 from me.