Key IDs should not be calculated from sha256(cjson(encoding(pubkey)))

[heartsucker]

From the spec:

The KEYID of a key is the hexdigest of the SHA-256 hash of the canonical JSON form of the key.

For future flexibility, I think key IDs should be calculated as sha256(pub_key_bytes). Right now the spec relies on the usage of CJSON and also a permanent fixed encoding of the public key.

[heartsucker]

I'm adding another note to this where we have had problems between PEM encoding RSA keys with one lib using PKCS#1 and one using SPKI giving us different strings / bytes for the same modulus / exponent in the public key.

For a point of comparison, does anyone know exactly what GPG does for calculating the fingerprints of RSA keys?

[SantiagoTorres]

I just ran into an issue similar to this here. So I thought it'd be worth bumping.

For a point of comparison, does anyone know exactly what GPG does for calculating the fingerprints of RSA keys?

This is specified in rfc4880 and we have implemented for in-toto here. The process is basically the hash over:

1. the byte \x99 (still a mystery to me)
2. length of the public key packet
3. hash of all the MPI's of the pubkey packet

[alyptik]

The 0x99 (0b_10011001) octet is used in place of the packet's actual tag octet (rfc2440 actually used the wording: "A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag").

They probably chose that particular octet as one that wouldn't conflict with any existing packet tags (v4 packet tags can't have bit 6 be 0 iirc), is still a valid packet tag with leading 1 bit that wouldn't break old programs (impossible to mistake for an MPI too), and it's also maybe a possibility the the bit pattern has some intetesting mathmatical property being a palindrome.

Last one is just a nerdy guess of course, haha.

[joshuagl]

There's a draft TAP for keyid flexibility https://github.com/theupdateframework/taps/blob/master/tap12.md

[jku]

I'm closing this as it does not seem to be a python-tuf issue: we do not choose keyids, securesystemslib does. Please open a securesystemslib issue if this is still valid

I think I agree with tap12: advantages of complex keyid generation algorithms do not seem at all clear to me when we could just require that keyids must be unique in that metadata only.