On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
On Thu 2016-04-07 20:33:56 -0300, Jon Callas <jon(_at_)callas(_dot_)org>
wrote:
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.
What is the utility here, specifically?
I appreciate making tracking/linkability harder as a goal, but i'm not
conivnced that this achieves that purpose.
Let me rewind then. PGP 2 had key-canonical fingerprints. There were issues
with them. Nothing particularly horrible, but they we all of the sort of fun
and games that you can play with the emergent properties of hash functions. And
really, I can't remember them all that well because that was ages ago.
PGP 3 and thus OpenPGP threw the creation time in there as a quickie salt. I
didn't do it. I don't know the full reasons.
I originally thought this was dumb. I got turned around, and believe that
salting the hash is a good thing. I know that I have used this property so that
I can re-use key material, but it's not the total reason.
I can think of a bunch of half-assed things someone can do with key-canonical
fingerprints if they are, say, the NSA. Nothing that's an attack, but just
stuff.
If anything, I think that salting the hash ought to be with more than the
timestamp. But really, I'd keep the fingerprint computation the same, just with
a more modern algorithm than SHA-1. The problem we're trying to solve is that
SHA-1 is old. I like to change only one knob at a time.
Most of all, I think that semantic properties like this shouldn't change
without a reason. At present, there are uses, questionable as they are, for
this, and why break it just because?
Right now, we know that for every fingerprint there is a key (modulo hash
collisions), but a key can have many fingerprints. Why to we want to change it
so that there's one-to-one correspondence between keys and fingerprints? This
sounds to me like it's vaguely surveillance-friendly.
Anyone who has the keys for alice(_at_)example(_dot_)com and
jobs(_at_)example(_dot_)com can
tell that these are the same keys, and can just join them in their
linkability/trackability database.
Furthermore, it introduces additional management problems for Alice; if
she loses control of the secret key material, she now has to ensure that
she's generated a revocation certificate for each "flavor" of it,
because the revocations are bound to the same material that the
fingerprint is bound to.
So? The reason to break the binding between key material and a certificate is
so that there's no binding.
Actually -- this sounds like as much a reason to salt it. There are more
reasons to revoke than loss of key material, and this means that revocation is
even less useful.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp