Re: Series of minor questions about OpenPGP 4

Hi.


On Fri, 2009-01-30 at 14:59 -0500, David Shaw wrote:
> Which signature is being revoked?  Without a signature target, it's
> not clear.
In a future revision of the RFC I'd suggest to add a "implementations
SHOULD use signature targets when revoking one or more signatures".

But the current way should still be allowed. I'd even clarify that it
works like this in the text.

btw: As far as I understand this works the following way:
- a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the
revocation signature AND with an earlier timestamp than the revocation
signature
BUT ONLY when calculated over the same data, which effectively means:
* Either all the 0x1Fs from the specific key (primary or sub)
* Or ALL 0x10,0x11,0x12,0x13s from the specific User ID
but NOT:
* from all User IDs or even all 0x10-0x13s and 0x1Fs

- a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME
creator as the revocation signature AND with an earlier timestamp than
the revocation signature
BUT ONLY when calculated over the same data, which effectively means:
* Only on the specific subkey, not from the other subkeys

- a 0x20 recovers everything and cannot be undone (with timestamp
tricks)

Is this correct?

Do these timestamp tricks work with subkeys and 0x28 revocation
signatures (and 0x18 subkey binding signatures)?
The RFC doesn't say anything whether the 0x28 should only affect
signatures BEFORE its own timestamp.


> Note that using the example above (sig+sig+revoke), this would result
> in there being effectively no signature.  That is intentional, not a
> bug: the second signature superseded the first signature, and then the
> revocation revoked the second.  End result: no signature.
This is in my opinion the "best" and probably "only" way it should be
handled.

Peter's idea that only the most recent valid signature per class (where
0x10-0x13 is one class, 0x1F is one, and 0x18 is one) MUST be used by an
implementation has a very little problem:
What if the most recent is revoked? This would mean, that the earlier
signature is used which is possibly bad.

So I'd suggest the way of gnupg (and perhaps other implementations?) to
be mandatory in a future RFC:
Let me copy it from David:
> the second signature superseded the first signature, and then the
> revocation revoked the second.  End result: no signature

Regards,
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

christoph(_dot_)anton(_dot_)mitterer(_at_)physik(_dot_)uni-muenchen(_dot_)de
mail(_at_)christoph(_dot_)anton(_dot_)mitterer(_dot_)name

smime.p7s
Description: S/MIME cryptographic signature