Retaining expired sigs

[David Shaw]

On Sat, Mar 19, 2005 at 12:02:45PM -0500, Jason Harris wrote:
> On Sat, Mar 19, 2005 at 01:24:13AM -0500, David Shaw wrote:
> > On Sat, Mar 19, 2005 at 12:22:54AM -0500, Jason Harris wrote:
>  
> > >   c) Always keep the latest (valid) signature from a given issuer, even if
> > >      it has expired.
> 
> > 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
> 
> That is not very defensive.  If an unsynchronized keyserver is used,
> a old copy of the key with only the unsuperceded sig(s) can be returned.
> Why open yourself to essentially a replay attack when you've already
> seen and can easily save certain strategic signatures from each issuer?
> Also, my desired semantics require keeping non-revocable sigs.  (See
> below.)

This troubles me a bit, as it is getting into packet manipulation
games.  It's hard to say which packets an unsynchronized keyserver (or
worse, an attacker) will suddenly resurrect.  However, I do agree it
does no harm to do this, and might help in some cases.  Ok.

>    This document is maintained in order to publish all necessary
>    information needed to develop interoperable applications based on
>    the OpenPGP format. It is not a step-by-step cookbook for writing an
>    application. It describes only the format and methods needed to
>    read, check, generate, and write conforming packets crossing any
>    network. It does not deal with storage and implementation questions.
>    It does, however, discuss implementation issues necessary to avoid
>    security flaws.
> 
> I maintain that it misses its stated goals of leading to interoperable
> applications and avoiding security flaws insofar as it leaves the sub-
> jects of expired and superceded signatures untreated.

I agree.  It's not just expired and superceded signatures.  There are
a good number of other semantic questions that are not covered in 2440
or 2440bis.  For example, the so-called "PGP trust model" is not
covered anywhere.  This is historical: the original plan for the IETF
group was that there would be multiple specifications (a message
format document, a trust model document, etc).  Unfortunately, only
the message format document was written, and it became 2440.

> > 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.
> 
> [moved from above]
> >     d) When stripping a signature, strip all earlier signatures from
> >        that particular issuer.
> 
> This will be safe iff the last (valid) sig. from a given issuer
> supercedes all previous sigs from that issuer, and, if expired,
> expires all previous sigs from that issuer, and, if a revocation
> signature, revokes all previous (even non-revocable) sigs from
> that issuer.  (NB:  Clearly, I don't think that last requirement
> can be met given even the most liberal interpretation of
> draft-ietf-openpgp-rfc2440bis-12.txt.  Without meeting all these
> requirements, you have to at least keep the non-revocable sigs too.)
> 
> Unless non-revocable userid cert. sigs are undone when newer revocable
> and/or expirable sigs that supercede them are undone (which neither of
> us agree with, correct?), you should keep the non-revocable sigs so
> they will take effect again once the sigs that supercede them become
> revoked/expired.

I'm not sure I agree with this.  I was under the impression you were
arguing for something else, so let me make sure we're both talking
about the same thing.  Given this case:

	   non-revocable sig    1-Jan-2000
	   revocable sig        2-Jan-2000
	   revocation           3-Jan-2000

One way of looking at this is the end result is nothing.  That is, the
revocable sig of 2-Jan-2000 has superceded the non-revocable sig of
1-Jan-2000, and then the revocation has revoked the sig of 2-Jan-2000.
There are no valid sigs left, and all three can be disregarded.

Another way of looking at this is that the revocable sig of 2-Jan-2000
has not superceded the non-revocable sig of 1-Jan-2000.  The
revocation of 3-Jan-2000 has revoked the sig of 2-Jan-2000, which
leaves the non-revocable sig of 1-Jan-2000 as valid and usable.

Now try this case:

	   non-revocable sig    1-Jan-2000
	   expired sig          2-Jan-2000 (expired 3-Jan-2000)

One answer here is that the expired sig of 2-Jan-2000 has superceded
the nonrevocable sig of 1-Jan-2000.  The end result is nothing and
both sigs can be discarded.

Another answer is that 2-Jan-2000 has expired, which leaves the sig of
1-Jan-2000 as valid and usable.

What are you arguing for?

David