Repository navigation
Loosen the keyid verification requirement? #305
Description
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.
Activity
trishankatdatadog commentedon Apr 26, 2024
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@multihashFor 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@122041dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8WDYT?
jku commentedon Apr 29, 2024
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:
joshuagl commentedon May 1, 2024
Thanks for the constructive proposal and kudos for coming up with an elegant solution. +1 from me.