Retaining expired sigs

[Jason Harris]

On Sun, Mar 20, 2005 at 08:36:09PM -0500, David Shaw wrote:
> On Sun, Mar 20, 2005 at 11:32:06PM +0100, Nicolas Rachinsky wrote:

> > What about different Levels (sig1..sig3) of signatures? If the first
> > one is sig3 and the second one sig1 and min-cert-level>1 there would
> > be a difference.
> 
> Yes, this is exactly why I don't want to do what Jason suggested.
> That would imply allowing a sig1 (which is ignored) to override a
> non-revocable signature, implicitly "revoking" it.

0x11 sigs are ignored by GPG by default, yes, but for users who set
"--min-cert-level 0," 0x11 sigs are just as valid as all the others.
In that case, they can't be construed as implicity revoking sigs at
other levels.

Also, when "--min-cert-level 1" is in effect, I imagine GPG will
discard all 0x11 sigs, whether revocable or non-revocable.  In that
case, a 0x11 sig. definitely can't even begin to implicity revoke sigs
at other levels.


On Sun, Mar 20, 2005 at 08:33:35PM -0500, David Shaw wrote:

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

Noted.

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

Bad example.  If a sig. can't be verified by the encryption client,
it must be disregarded and therefore can't supercede any other sigs.

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

Again, bad example.  "--min-cert-level 2" (no matter how ridiculous
you may personally find its use) will make GPG disregard 0x12 sigs.

I really don't think it is worth trying to protect against these
scenarios.  A user can simply remove any non-revocable sigs they don't
want in their local keyring.  This cannot be protected against and is
certainly not an act of revocation by the issuers of non-revocable sigs.
Lowering the sig. level initially set in a non-revocable sig. can never
"revoke" that sig. either, IMO (as my past messages should have made
clear), and even GPG's --min-cert-level doesn't create the conditions
for this to happen (as explained above).

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

OK.

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

Gah!  PGP 8.1 allows non-revocable sigs to be revoked?!

-- 
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/20050320/74e936d1/attachment.pgp