On Apr 8, 2016, at 7:49 PM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
On Fri 2016-04-08 15:32:32 -0300, Jon Callas <jon(_at_)callas(_dot_)org>
wrote:
One of the ideas we had a long time ago was that the "fingerprint"
actually has two fields in it. A tag and a value. I'm still fond
myself of the fingerprint that is
<algorithm-id>:<algorithm-value>
but I'm not wedded to the syntax. I like the idea; I don't care
about the syntax.
The sense i got from the group was that we wanted one (and exactly one)
fingerprint for any given key.
the proposal above means that i could compute a fingerprint for key X,
and you could compute a fingerprint for key X, and then when we go to
compare them they could be different (because one of us chose a
different algorithm id than the other). This makes fingerprint
comparison a crapshoot, or requires one side of the comparisons to
generate all possible fingerprints before they discover what the other
side has done.
Noted.
I will mention that the advantage of a generic scheme is that it doesn't have
to be revisited later when there's a new cool hash function that we all should
use.
But the real reason for bringing that back was to give Bryan a hand. I see what
he's wanting to do. He's wanting to create something that I will call the
"authentication string."
At present, we use the key fingerprint as the authentication string. The mining
protection he's suggesting isn't a bad thing. My raised eyebrow comes from
conflating the two. We need to have a "DB handle" and I believe the DB handle
needs to be easy to compute (key-canonical is an orthogonal issue). The
fingerprint gets used all over the place, especially in its truncated form as
key-id.
So a way to get both is to make them not the same thing. Have it so that the
thing that you print on your business card is the authentication string, and
the thing that the software is using a lot is the db handle.
As it is, there are "fingerprints" used all over the place that aren't the
user-visible one anyway, because the user-visible one is the fingerprint of the
top-level signing key.
So stepping back even further, to have our cake and eat it two, we want to
separate the two functions.
Anything that does that seems like a win, not just generalized fingerprints.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp