Open jku opened 2 months ago
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?
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:
Thanks for the constructive proposal and kudos for coming up with an elegant solution. +1 from me.
WRT keyids, we currently say this:
I believe there is a consensus that these requirements are not useful and are even harmful:
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
Both are "should" in order to keep compatibility with current implementations while guiding new implementations into the most useful functionality.