Retaining expired sigs

[David Shaw]

On Fri, Mar 18, 2005 at 02:06:46PM -0500, Jason Harris wrote:
> 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.  :)

No.  I modified GPG to help remove *expired signatures*.  This has
nothing to do with the GD specifically.  I did, incidentally, consider
a "don't export expired GD keys" flag, but that is not what the
feature is.

> 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.)

I don't disagree with this.  It's not unreasonable to remove them, but
it doesn't happen that way today.  The problem at hand was expired
sigs, so that is what I addressed.

Removing superceded signatures, however, re-raises the semantic
questions I asked in my last mail.  What algorithm runs first: the
"remove superceded" or "remove expired"?  Depending on which runs
first, you can get a different result.

> > 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.

But should it be?  My point is not to say that such-and-such is the
answer.  My point is to say that it is not at all clear what the
answer should be.  I may take some time this weekend and run a few
test cases against other OpenPGP implementations to see what they do.

> 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.

Only if the right behavior is that expired signatures *should*
supercede earlier, unexpired signatures.

If the answer is that expired signatures should supercede, then the
current implementation of the expired sigs filter is insufficient - it
needs to remove the earlier sigs as well to avoid re-awakening an old
signature.  If the answer is that expired signatures should not
supercede, then the current implementation is correct.

Which do you favor (and why)?  Does every sig stand alone, or can sigs
only be interpreted in terms of a series?

I vaguely lean towards the idea that expired signatures should not
supercede earlier unexpired signatures (the "sigs stand alone"
answer), but only vaguely.  I find the simplicity of it attractive.
Interpreting sigs in a series raises a number of dangerous problems,
like what happens when a sig is "unrevoked" by an attacker by removing
packets from the key.

David