Retaining expired sigs

[Jason Harris]

On Fri, Mar 18, 2005 at 02:37:33PM -0500, David Shaw wrote:
> On Fri, Mar 18, 2005 at 02:06:46PM -0500, Jason Harris wrote:

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

Indeed, why is why the correct answer is:

  c) Always keep the latest (valid) signature from a given issuer, even if
     it has expired.

Sigs (esp. revocations) with targets should always be kept, too, lest
their targets resurface alone and therefore unmodified.

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

Hopefully they will behave as I describe above.

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

Per draft-ietf-openpgp-rfc2440bis-12.txt, section 5.2.3.3, I think
the intent is clear that an expired selfsig on a userid is the same
as a revoked selfsig on a userid.  There is no reason for this not
to apply to non-selfsigs as well.

Section "0x30: Certification revocation signature" mentions (non-
targetted) 0x30 revocations as applying to "an earlier" sig.  It
also says: "The signature should have a later creation date than
the signature it revokes."  I believe it is generally understood
that "all earlier" sigs are affected by non-targetted 0x30 sigs.

Section 5.2.3.12 (non-revocable flag/subpacket) is very specific
that no revocations apply to non-revocable signatures.  However,
it mentions nothing of non-revocable sigs being superceded.

(Gah!  "key holder" and "keyholder" are both used in the draft.)

> 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

Actually, GPG needs to retain the latest valid sig., even if it has
expired, so that it will be around to take precedence over older sigs.

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

I think it is understood that pubkeys and subkeys cannot be unrevoked
after being revoked and non-revocable signatures cannot be revoked
after being created, but otherwise anything can be superceded.

The RFC fails to directly address the issue of a non-revocable sig.
being superceded by a revocable one which is then revoked, however.
In the strictest sense, non-revocable sigs cannot be undone, period,
by any mechanism.  This is certainly needed when a selfsig specifies
a designated revoker, but I think it is good to treat all other non-
revocable sigs as "backups" or "fallbacks" that can be superceded
temporarily but always return as "standing orders" until superceded
again.

If this is not (to be) the case, then non-revocable sigs should really
be called "non-modifiable" sigs.

-- 
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/20050319/fcbffd97/attachment-0001.pgp