Re: [openpgp] Should fingerprints be "key-canonical"?

[Jon Callas <[e-mail]>]

>> If you do #1, then you make it so that you can't use the same key for multiple purposes. You can't for example use it for aliases and nyms. I think #1 is a bad idea because it tends to turn the fingerprint into a tracking identifier and I think that making your crypto be implicitly tracking-friendly is a bad idea.
> 
> That’s a really good point - I definitely agree with the desirability of making fingerprints less useful as tracking identifiers.  On the other hand, one might argue that there are other ways to address this, e.g., by just having separate keys (or subkeys?) representing nyms.  If you *really* want your nyms to be unlinkable to each other it doesn’t seem avoidable that they’ll need to be based on separate keys and not just different fingerprints for the same key.

Yes, because I can tell you that it's *really* useful to be able to reuse the key material from [e-mail] for (e.g.) [e-mail] or security, or whatever. I've done it a lot over the years.

There's a related trick that people do in X.509 certs -- you keep a lifetime for your *key* that is longer than the lifetime of the certificate. There are a lot of reasons for it, and a lot of people do it, despite it making the PKIX purists hyperventilate. 

The trick of fingerprint = F(key, stuff) has a lot of uses. We can debate the F, and the stuff, but why toss the principle out? We don't want to make X.509 certs and S/MIME more useful.


> 
>> So let's talk about #2 and #3 as somewhere on a continuum of saying that the fingerprint is a computable database identifier that provides some onewayness from key to fingerprint.
>> 
>> The way OpenPGP presently does it is kinda meh. It achieves the goal that knowing a fingerprint can find a key, but is merely onto, not one-to-one. It is, however, the way that it is.
>> 
>> If you change it, you end up with unknown breakage. I also don't see a *goal*. What problem are you trying to solve? I recognize that creating a new fingerprint algorithm provides an opportunity, but I have to ask why.
>> 
>> If you specify extra data to be thrown in, it gives the future more places to attack fingerprints in clever ways. 
> 
> Agreed, and this consideration definitely seems to argue for a strict 1-to-1 fingerprint-to-key relationship.

So here's what I suggest -- either keep the way that at present the creation time serves as salt, or do something simple like add in an optional short buffer. Length of the hash is fine.

	Jon