On Jan 18, 2011, at 5:35 PM, Daniel Kahn Gillmor wrote:
I think that there must be only ONE string called THE fingerprint of a
certain
public key.
why? we currently have three strings that are frequently used to
identify keys with varying levels of assurance of "uniqueness" -- the
32-bit keyID (no guarantee at all, trivially spoofable), the 64-bit
keyID (more difficult to spoof), and the 160-bit SHA1-based fingerprint
(believed to be invulnerable to preimage attacks given the state of
knowledge of math and available computer hardware). I'm aware that
these are derivable from each other, but it doesn't seem to change the
fact that we're using them in a comparable way right now.
What significant problems will we encounter by adding a 4th identifying
shorthand variant (hopefully with stronger guarantees of "uniqueness"
than the existing three) that people can use if they want the stronger
guarantees?
I think we're overloading the term "fingerprint" and it's causing confusion.
The original mail was a desire to help disambiguate the signer of a particular
signature to resist a particular attack. Of course, we have a
thing-that-disambiguates already - the key fingerprint, which is already well
defined in the spec and very widely implemented.
I don't want to invent a brand new thing-that-disambiguates that a) only
applies to making signatures, and b) is not compatible with the existing
method. Like Werner, I don't want to have to support it more-or-less forever
after V5 obsoletes it, and it also feels rather like an end-run around the
"let's wait for SHA-3" consensus here on fingerprint changes.
My proposal is to make a subpacket that is defined as the fingerprint of the
signing key plus a version byte. This is an excellent disambiguator. As you
point out, it is believed to be invulnerable to preimage attacks given the
state of knowledge of math and available computer hardware. If and when we do
V5, the same subpacket can be used for the V5 fingerprint (whatever that turns
out to be), so we're not being forced to support an obsolete subpacket.
Think of it as an improved Issuer (#16) subpacket.
Shorter version of all that from your original email:
Alternately, what about a new subpacket type that simply includes the
entire 160 bits of the issuer's fingerprint? (the "full fingerprint"
proposal)
Add a version byte to the front of that, and we're talking about the same thing.
David