Jon Callas <jon(_at_)callas(_dot_)org> writes:
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.
It threw in both creation time AND the (optional) expiration time!
Please don't forget the expiration time!
Unfortunately that was removed in v4 (but I don't remember why).
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
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp