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
Attachment:
signature.asc
Description: OpenPGP digital signature