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

David Shaw <dshaw@jabberwocky.com> Tue, 05 May 2009 00:24 UTC

Cc: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Message-Id: <713E06B3-4432-44C3-B6BF-D6A2528885CA@jabberwocky.com>
From: David Shaw <dshaw@jabberwocky.com>
To: "Daniel A. Nagy" <nagydani@epointsystem.org>
In-Reply-To: <49FF6677.7070907@epointsystem.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Fix revocation keys instead of fingerprints? (was Re: Non-SHA-1 fingerprints)
Date: Mon, 04 May 2009 20:17:10 -0400
References: <5F766368-BB36-4076-807D-E0CEDB7B0026@jabberwocky.com> <49FF6677.7070907@epointsystem.org>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk

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

Non-SHA-1 fingerprints David Shaw
Re: Non-SHA-1 fingerprints Daniel A. Nagy
Re: Non-SHA-1 fingerprints Daniel A. Nagy
Re: Non-SHA-1 fingerprints Ian G
Re: Non-SHA-1 fingerprints Jon Callas
Fix revocation keys instead of fingerprints? (was… David Shaw
Re: Non-SHA-1 fingerprints David Shaw
decimal fingerprints [was: Re: Non-SHA-1 fingerpr… Daniel Kahn Gillmor
Re: Non-SHA-1 fingerprints Daniel Kahn Gillmor
Re: Fix revocation keys instead of fingerprints? … Daniel Kahn Gillmor
Re: Fix revocation keys instead of fingerprints? … Daniel A. Nagy
Re: decimal fingerprints [was: Re: Non-SHA-1 fing… Daniel A. Nagy
Re: Fix revocation keys instead of fingerprints? Werner Koch
Re: Non-SHA-1 fingerprints "Hal Finney"
Re: Non-SHA-1 fingerprints Ingo Klöcker
Re: Fix revocation keys instead of fingerprints? … David Shaw
Re: Fix revocation keys instead of fingerprints? … Daniel A. Nagy
keyids vs. fingerprints [was: Re: Fix revocation … Daniel Kahn Gillmor
collision-resistance and self-signatures [was: Re… Daniel Kahn Gillmor
Re: collision-resistance and self-signatures [was… Daniel A. Nagy