Re: including the entire fingerprint of the issuer in an OpenPGP certification

[David Shaw <[e-mail]>]

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