Retaining expired sigs

David Shaw dshaw at
Mon Mar 21 02:33:35 CET 2005

On Sun, Mar 20, 2005 at 03:10:44PM -0500, Jason Harris wrote:

> > Seriously, think about it:
> > 
> > 	   non-revocable sig   1-Jan-2000
> > 	   expiring sig        2-Jan-2000 (expires 10-Jan-2000).
> > 
> > Now, say it's January 3rd.  According to what you want, the signature
> > that gets used is the 2-Jan-2000.  Then, suddenly, on 10-Jan-2000,
> > when that signature expires, the 1-Jan-2000 signature is used.
> (Yes, I continue to advocate this (superceding of non-revocable sigs).)
> >   End result: there is always a signature.
> > 
> > According to what actually happens, the signature that is used is
> > 1-Jan-2000.
> > 
> >   End result: there is always a signature.
> There is only ever one signature (that GPG uses):  the 1-Jan-2000
> signature, correct?
> > I suggest that if it bothers you all that much, you pretend that it's
> > doing what you want.  It's not like there is a way to tell the
> > difference.
> I can imagine scenarios where there would be a difference, regardless
> of how useful others may consider them in practice.  For example, I
> issue a non-revocable 0x12 sig.  Later, I want to upgrade it to a
> 0x13 sig. (revocable or non-revocable).  IIUC, GPG will always use
> the non-revocable 0x12 sig., correct?
> If so, I think we're communicating just fine, but have a difference of
> opinion over this issue.

Ok, I see where you're coming from.  You are correct: I do feel that a
non-revocable signature must be a non-revocable + non-supercedable

I feel it really needs to be this way to fulfil the spirit as well as
the letter of the standard.  There is little point to a non-revocable
signature (described as "They represent a commitment by the signer
that he cannot revoke his signature for the life of his key." in the
spec) if that signature can be effectively revoked by superceding it
with an unusable signature (say, one with an unusable hash algorithm).

The nice thing (in terms of the 0x12/0x13 question) is that it doesn't
matter: GPG doesn't interpret 0x12 any differently than 0x13.  Thus
(from the earlier example), it genuinely makes no difference if the
1-Jan-2000 signature is 0x12 and the 2-Jan-2000 signature is 0x13.  So
long as GPG interprets either of those as a signature with no
qualifications, then there is no advantage or disadvantage to either
signature being used.  Either one is just "signature".

I'm aware that you want GPG to interpret 0x12 and 0x13 (and 0x11)
differently, but that's already been discussed a number of times and
will no doubt be discussed again.  GPG doesn't do it today.

> > > BTW, what has your testing of other (OpenPGP(?)) encryption programs
> > > uncovered?
> > 
> > Haven't checked yet.  I don't know that it'll be terribly illuminating
> > on the subject of non-revocable sigs since so far as I know, GnuPG is
> > the only one that implements them (except for the usual use in
> > designated revokers).  It might reveal something interesting about
> > expiring sigs though.
> OK.

I just checked PGP 8.1 and the results were interesting.

When importing a sig+expired sig set, PGP does what we ended up with:
it strips the sig and leaves the expired sig.

When importing a non-revoke-sig + revoked sig set, PGP doesn't strip
anything, but does ignore the non-revokable sig (it isn't even visible
in the GUI).


More information about the Gnupg-users mailing list