Re: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fing

Hi,

David Shaw wrote:
> 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)
That's not the fingerprint. That's the key ID.

> 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)
In case of collision, both colliding pre-images are done by the same entity.

> Perhaps we'd do better by leaving fingerprints alone and instead fixing
> how we specify revocation keys?
There is nothing wrong with them at present.

Well, actually, I would argue that revocation is currently over-designed. Since
revocation is an irreversible act, there is no need for the heavy artillery of
digital signatures for that purpose. All the s2k specifiers used for symmetric
encryption would do (in a hashed sub-packet together with the resulting
symmetric key) and inserting a non-hashed sub-packet with a matching revocation
passphrase into the revoked signature would be just as secure a method for
revocation than adding a revocation signature packet.

There is no need for asymmetric crypto for revocation. Instead of revocation
signatures, it would be perfectly safe to use revocation passphrases.

> 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.
Again, collisions are not important in this case. Collisions only matter when
the signed information is compiled by a different entity than the signer.

With a hash that is one-way but not collision resistant, you can do two keys
that have the same fingerprint. So whay? Both are under your control, a
signature with either is your signature.

> 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?
It costs more and does not provide any extra security. I mean there is no attack
that can be prevented in this way. Therefore, it is less secure.

>  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.
It still makes the key fatter without making any attack more difficult. It won't
make illegitimate revocation more difficult.

-- 
Daniel

signature.asc
Description: OpenPGP digital signature