-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Key IDs should not be calculated from sha256(cjson(encoding(pubkey))) #442
Comments
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? |
I just ran into an issue similar to this here. So I thought it'd be worth bumping.
This is specified in rfc4880 and we have implemented for
|
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. |
There's a draft TAP for keyid flexibility https://github.com/theupdateframework/taps/blob/master/tap12.md |
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. |
From the spec:
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.
The text was updated successfully, but these errors were encountered: