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

[Daniel Kahn Gillmor <[e-mail]>]

On 01/18/2011 05:03 PM, Daniel A. Nagy wrote:
> There are specific use cases that I am interested in, where including the
> creation date in the fingerprint hash causes problems. If anyone is interested,
> I can describe them in necessary detail.

I'd like to read about (or be pointed to) the necessary detail.

> I believe you mis-interpreted Jon's suggestion. He was suggesting to treat the
> fingerprint field as a free-form string within the signature subpacket. Nothing
> more and nothing less.

i'm pretty sure that's not what he suggested, actually.  But clearly it
wasn't successfully communicated to everyone, since we appear to have
different interpretations.  Jon, can you clarify what you meant?

> Key servers must also eventually treat
> fingerprints as (possibly limited-length, but by no means fixed-length) strings.

Why?  Shouldn't keyservers be responsible for calculating the
fingerprints themselves?  treating fingerprinting as a total black box
seems like it loses several of the really useful properties of fingerprints.

> 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?

	--dkg