GD doesn't always accept revocations

David Shaw dshaw at
Wed Feb 9 22:25:48 CET 2005

On Wed, Feb 09, 2005 at 04:14:51PM -0500, Jason Harris wrote:
> On Wed, Feb 09, 2005 at 03:32:57PM -0500, David Shaw wrote:
> > On Wed, Feb 09, 2005 at 03:26:19PM -0500, Jason Harris wrote:
> > > Obviously, the keyholder didn't heed the FAQ and has left 0x3EA5F9EF
> > > on the GD.  Unless this is corrected, ldap://
> > > will incorrectly serve the unrevoked version of the key for the next
> > > 6 months.
> > 
> > Yes.  I don't think this is the best design.  I understand the desire
> > to keep revoked keys off of the GD, but it's not clear what to do in
> > this case (an unrevoked key on the GD is suddenly revoked).
> It needs only to verify the revocation and remove the key immediately.

Well, that's one possible answer.  Why don't you suggest it to the GD

> The key was revoked by the keyholder, so it cannot be re-added to the
> GD unless its revocation certificate is removed.  This is very simple
> to do with a tool like gpgsplit, and is therefore an easy attack to
> perpetrate against the GD and keyholders of revoked keys.  (I classify
> it as an attack because it gets the GD to send confirmation emails for
> "useless" keys, anyone answering the unencrypted challenges causes the
> GD to store "useless" keys, etc.)
> This also applies to expired (v4) keys, as long as at least one (earlier)
> selfsig didn't expire the key.

Why go through a lot of bother to find an expired or revoked key which
you then manipulate into being acceptable?  Just make a brand new key
with your victim's email address and submit that.  It's the same


More information about the Gnupg-users mailing list