Documenting or creating a TAP to describe keyid_hash_algorithms

Hello again,

Would you consider documenting, or possibly writing a TAP, to describe the keyid_hash_algorithms field in a key definition? As I upgrade go-tuf (and eventually rust-tuf) to the TUF 1.0 Draft, I am also updating it to be compatible with the metadata produced and consumed by this project. In order to do so, I need to also produce a compatible keyid_hash_algorithms field the metadata I produce. However, I’m not completely sure what I am supposed to do with this field when I receive it from python-tuf.

It appears this field originally came from https://github.com/secure-systems-lab/securesystemslib/pull/37. As best as I can tell, it is present so that a client knows which algorithm was used to compute a keyid, so it can verify that a keyid is correct. Is this right, and are there other ways the keyid_hash_algorithms is used?

[lukpueh]

Another argument for loosening the keyid specification is interoperability with existing PKI-infrastructure. Here are two data points that support that claim.

• Silvano Cirujano Cuesta recently wrote about interoperability with smartcards that have custom keyids (see “[tuf] Importance of keyids consistency” on [e-mail]).

• the securesystemslib.gpg subpackage, does not calculate keyids according to the TUF spec, but instead uses OpenPGP fingerprints for keyids, to make them compatible with system GPG keyrings. securesystemslib.gpg keys are not yet used in python-tuf, and it would probably need some modifications to support non-standard keyids (see e.g. tuf.keydb. create_keydb_from_root_metadata).

[awwad]

IMHO:

What hashing algorithm is used when a key ID is calculated is an implementation detail. It is not a property of the key. Keys should not each individually define a list of hash algorithms that are acceptable for referring to those keys, leading the key to change any time implementation details do. Referring to a key is something that signatures, delegating metadata, and clients do. I doubt there is any serious need to permit an implementation to support multiple different key ID hash algorithms for the same key type; however, if there is, it should still not be in the hashed value of the key itself (see below).

Refresher: Recall that keys in TUF show up in three places: in key representations themselves, in signatures, and in delegations. Key IDs are important wherever the possibility exists of large key values that are inconvenient to represent repeatedly (basically, whenever you support using something other than elliptic curve crypto, or wrap that in something like OpenPGP).

• A key does not need to indicate its keyid (or how to determine its keyid).
• A signature helpfully prompts you with the keyid of the key that made it (so that you don’t have to waste time on every other authorized public key in a delegation).
• A delegation authorizes keys by keyid.

TODO:

• We should, in the reference implementation, remove key_id_hash_algorithms from key representations, as soon as practical, before folks start sticking this stuff in their own implementations… (It’s far less effort to PR to the reference implementation than to sign your implementation up for future pain here, I think.)
• No other implementations should use keyid_hash_algorithms entries in keys. If metadata must define this behavior, it should be a root metadata setting; if that is truly not possible due to diversity (Uptane might be a use case – ECU limitations), then this behavior should be defined in the key listings in delegating metadata only. In that situation, for convenience, it can be added to signatures (that that would be under attacker control should not be an issue – LMK if you want more info).
• If anything should be added to the spec about this (via a TAP or otherwise) it should be the prior point: don’t stick this stuff in keys.

I’ve said previously that the result of the current policy in the reference implementation (aside from the fact that it is confusing) is that trying to refer to a key in a different way requires changing the key’s identity and breaking any delegations to it. It will cause (and has caused) headaches. Break metadata delegations once and remove this for the sake of clarity and simplicity, instead of breaking delegations whenever hash algorithms need to change. This change should not cost us any interoperability.

Re. GPG keys: for my part, when I’ve had to support OpenPGP keys and signatures (basically, for YubiKey interfacing), I’ve used them as a vector for more typical ed25519 signatures: in signatures, in delegating metadata, and in the verification process, I still refer to and use the public key using its underlying value (not the OpenPGP keyid).