GD doesn't always accept revocations
dshaw at jabberwocky.com
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://keyserver-beta.pgp.com
> > > 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