On Jan 31, 2009, at 3:59 PM, Christoph Anton Mitterer wrote:
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?
Not exactly. A revocation revokes *one* signature. Given this:
Signature (timestamp 1)
Signature (timestamp 2)
Revocation (timestamp 3)
The end result is no signature - but the reason is not because the
revocation has revoked both signatures. The reason is because the
signature at timestamp 2 has replaced the signature at timestamp 1,
leaving this:
Signature (timestamp 2)
Revocation (timestamp 3)
And then the revocation revokes the one remaining signature.
David