Retaining expired sigs

[Jason Harris]

On Fri, Mar 18, 2005 at 01:23:39PM -0500, David Shaw wrote:
> On Fri, Mar 18, 2005 at 12:30:32PM -0500, Jason Harris wrote:
 
> > Everyone who feels expiring signatures hamper their keys should
> > raise the issue with those generating such burdensome signatures.
> 
> That's somewhat impractical.  Should we ban expiring signatures?  You
> seem to have a problem with the GD because it issues fast-expiring

(Well, you modified GPG to help remove the GD sigs, not me.  :)

> > Furthermore, I don't see a lot of difference between expired signatures
> > and superceded signatures, yet GPG doesn't (currently) throw away the
> > latter:
> 
> There is a significant difference.  An expired signature is *expired*.
> It's dead as Marley.  A superceded signature is very much alive, and
> is used *unless something better is present*.

Right, and in the example, something better is present.  GPG knows
the newer sig. is valid, so the older sigs contribute nothing to
the current state of the key.

> In GPG, an expiring (but not yet expired) signature will supercede an
> earlier signature from the same signer.  Once this signature expires,
> it still supercedes the earlier signature (thus effectively disabling
> the original signature).  Thus you have a perfectly valid signature
> that is disabled by an expired signature.  This is one of those
> interesting areas of the trust model where things get fuzzy: it's not
> clear what the semantics should be here, since it requires GPG to
> guess what the signer "really meant" to say, and worse, guess this
> without all the data at hand.

OK, but none of the signatures in the example have expirations.

My point is that once GPG sees a newer signature that overrides an
older one, it can safely remove the older one, in all cases, in the
interest of keeping keys clean.  (Of course, the newest sig. should
be valid, and the older sigs should be checked for validity as well,
lest we run into a long keyid collision.)

> It gets messy very fast: if I sign a key with no expiration, then sign
> it again with an expiration, then the second signature expires - is my
> original signature still valid?  Maybe I actually revoked the first

By your own explanation above, no.

> signature, but the revocation packet isn't present right now, or was
> stripped out by the key owner.  Maybe the second signature was a short
> term signature because the original signature wasn't present at that
> time.  Add to that the problems of packets being missing and bad
> clocks, and it's a very fuzzy question indeed.
> 
> I recommend that if people want to replace an earlier signature with a
> new, expiring, signature, they first revoke the earlier signature, and
> only then issue the new expiring signature.  This way there are much
> fewer questions as to the intent of the signer, and many fewer
> opportunities for the trust code to guess wrong.

Therein lies the problem:  GPG, by removing expired signatures
(at all), is removing history.  As you point out, this can lead
to problems when the expired signatures are no longer available
to supercede earlier, unexpired signatures.

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: not available
Url : /pipermail/attachments/20050318/827407b5/attachment.pgp