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.anton.mitterer@xxxxxxxxxxxxxxxxxxxxxx mail@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME cryptographic signature