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 alice(_at_)example(_dot_)com for (e.g.)
jobs(_at_)example(_dot_)com 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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp