Retaining expired sigs
dshaw at jabberwocky.com
Sat Mar 19 20:26:07 CET 2005
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
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
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
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?
More information about the Gnupg-users