On Fri, Jan 30, 2009 at 08:17:41PM +0100, Peter Thomas wrote:
On Thu, Jan 29, 2009 at 11:30 PM, David Shaw
<dshaw(_at_)jabberwocky(_dot_)com> wrote:
It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F
signature revokes (potentially) all of them that are a) from the same
issuer (or from that issuer's designated revoker), and b) timestamped
earlier than the revocation. It cannot revoke ones that come after
it.
Uhm? Why this? I'd thought it would only revoke the specifically
revoked signature, as "the signature is computed over the same data as
the certificate that it revokes".
Am I missing something?
Take this example:
User ID
0x10 signature on that user ID (timestamp 1)
0x10 signature on that user ID (timestamp 2)
0x30 revocation (timestamp 3)
Which signature is being revoked? Without a signature target, it's
not clear.
Even then there is the possibility of confusion of which signature you
intend to revoke. In those cases, you can always specify a particular
signature to revoke using the Signature Target subpacket in the
revocation. Arguably, you could even revoke multiple signatures with
one revocation by using multiple subpackets.
Not, it should be pointed out, that many (any?) implementations
support Signature Targets yet. But the semantics are there.
Uhm ok,.. so how does an implementation figure out which certificate
is revoked by a revocation signature?
I can't speak to any other program, but GPG finds the latest
(i.e. most recent) signature or revocation from the issuer. If that
turns out to be a revocation, then there is effectively no signature.
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.
David