Retaining expired sigs

[David Shaw]

On Sat, Mar 19, 2005 at 12:22:54AM -0500, Jason Harris wrote:

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

Why keep around the last expired signature and remove all others?  I
prefer:

    d) When stripping a signature, strip all earlier signatures from
       that particular issuer.

Remember that the original thing that spawned this thread was the
desire to keep expired signatures from clogging keys.  In the case
where the latest signature is expired, you don't need to keep *any*
signatures.  Using your desired semantics (superceding), the most
recent sig invalidates all earlier ones.  That leaves you with a
single expired sig, which can be removed since there is no longer an
earlier sig to supercede.

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

I don't think it's viable to argue the "what if a signature comes
back" game, since if you are presupposing packet manipulation, then
most of the discussion we are having here is moot anyway.

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

Keep reading to the end of 5.2.3.3.  The draft, in fact, intentionally
does not answer the question of multiple self-sigs.  There is some
advice about interpreting selfsigs as narrowly as possible, and
biasing towards more recent, but "An implementation that encounters
multiple self-signatures on the same object may resolve the ambiguity
in any way it sees fit" means pretty much what it says.

I'm not adverse to changing the code to implement superceding, but I
don't think you can (or really need to) rationalize it from 2440bis.

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

Remember that OpenPGP does not really specify validity semantics.
Unfortunately (or fortunately depending on how you look at it), some
semantics have crept into what is supposedly just a message format
document.  In fact, this is another grey area: subkeys can
theoretically be unrevoked by issuing a new binding signature, just
like user IDs can.  GnuPG doesn't do this for simplicity, but that's
an implementation choice, and not specified (either way) in the
standard.

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

Grey area again.  I happen to agree with part of what you say
(non-revocable sigs can be superceded), but this is not specified in
the standard anywhere.

Dragging the conversation out of the standard and into implementation
details for a moment, I'm rather inclined to change the expired-sigs
trimming code to implement the change (d) from above.  It's consistent
and safe from signature resurrection problems.

David