ietf-openpgp
[Top] [All Lists]

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

2011-01-18 17:37:05

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

<Prev in Thread] Current Thread [Next in Thread>