On May 4, 2009, at 6:04 PM, Daniel A. Nagy wrote:
David Shaw wrote:
Now that I think about the variable-hash fingerprint question a
bit, I'm
concerned about things like RFC-4398, which uses OpenPGP
fingerprints in
DNS.
For fingerprints, MDC and self-signatures, collision-resistance does
not matter,
only the one-way property. So I think it is totally safe to postpone
discussion
until SHA3 is selected.
It's a larger problem than just fingerprints. We also use a
fingerprint as a specifier inside the revocation key subpacket, to
designate which key can be used to issue revocations on our behalf.
The thing is, though, a fingerprint isn't really a very good
revocation key specifier:
Fingerprints:
* Must be human-readable
* Needs to be small to be useful
* Can collide to some small amount (4880 even documents that they
collide in section 12.2)
Revocation key specifier:
* Does not need to be human-readable
* Has much looser size requirements (shouldn't be enormous, but
certainly can be bigger than 160 bits without hurting anything)
* Should never collide (we don't want the wrong key being able to
revoke our key)
Perhaps we'd do better by leaving fingerprints alone and instead
fixing how we specify revocation keys?
We could try to come up with a new non-colliding way to disambiguate
keys, but fundamentally, anything that is smaller than the key packet
itself can still collide. So instead, why not define a new revocation
subpacket that contains the class octet from the old revocation key,
and the rest of the subpacket is simply a copy of the public key
packet in question? I don't mean the whole transferable public key,
of course, just the contents of packet #6. This public key packet
doesn't need any self-signatures or anything else like that, as it is
implicitly authenticated by the signature that carries the revocation
key subpacket.
David