bug: gpg fails to allow update of OpenPGP certification after expiration

[Daniel Kahn Gillmor]

My certification on a key+userID recently expired.  I went to re-certify
it, and gpg failed to allow the re-certification, with the following
interaction:

> "foo (redacted)" was already signed by key D21739E9
> Your current signature on "foo (redacted)"
> has expired.
> Do you want to issue a new signature to replace the expired one? (y/N) y
> Nothing to sign with key D21739E9
> 
> Key not changed so no update needed.

Note that no additional certification was added.

There were two certifications by D21739E9 on the key in question already:

 A) one certification from 2008 with no expiration date
 B) a certification from 2010 with an expiration date in early 2011

Given the OpenPGP standard, B should supercede A.

It appears that what happens is that when the user says "y" to the
prompt, gpg effectively deletes signature B from the temporary view of
local keyring, leaving it with A.  It then decides that A is sufficient,
and declines to do anything.  Since no changes have been made, it
doesn't even save the updated local keyring.

I have two workarounds:

0) manually delete A from my local keyring first, with something like:

 gpg --edit-key $KEYID
  1
  delsig

1) use gpg's --expert flag to force my way through.

I note that if i use either of these methods to create a new
certification, then my local keyring ends up without (B) at all (though
it is of course re-fetchable from the public keyservers).  I consider
this is surprising behavior, though given that i'm in workaround
territory, i suppose any surprises should be expected.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110517/d08f29d3/attachment.pgp>