On Sat, Jan 31, 2009 at 01:04:33AM +0100, Peter Thomas wrote:
On Fri, Jan 30, 2009 at 8:59 PM, David Shaw
<dshaw(_at_)jabberwocky(_dot_)com> wrote:
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.
Ahhhh....
First of all,.. the different types of revocation signatures are NOT
calculated of the signature they revoke, but the data the signature to
be revoked was calculated over, right?
Right.
But the following is still unclear:
a) when I use a 0x20 key revocation signature:
Am I correct that the explanation on page 21 says: A key having a
revocation signature is completely invalid including all it's UIDs,
subkeys, etc. and this cannot be undone in any way?
Yes. However note that you can un-revoke a key by removing the
revocation signature. That's very difficult to do in practice
(keyservers would have the revoked copy).
(Of course the subkeys could still be used attached to another primary.)
Right.
I mean the following doesn't work, right?
Primary key
|->UID
|--->0x13 on that UID
|->Subkey
|--->0x18 on that subkey
now I add a:
|-> 0x20 key revocation at 12:00 making the key unusable (forever?)
at 13:00 I add new UID's/0x13s/Subkeys/0x18s
|->UID2
|--->0x13 on that UID2
|->Subkey2
|--->0x18 on that subkey2
But the whole thing would still be revoked, right?
Right.
b) when I use a 0x28 key revocation signature:
Does this (according to the RFC) make the subkey forever unusable, as
above with the 0x20s?
Or would issuing a subkey binding signature more recent than the 0x28
bring it (the subkey) back?
That's a good question. The RFC specifies that a subkey may have one
(and only one) binding signature, and zero or one revocations. Thus
you cannot resign a subkey to un-revoke it. I don't recall if that is
the reason the key grammar enforces exactly one binding signature, but
it would seem to follow naturally from that grammar.
Of course, you could strip off both the binding sig and revocation sig
and just make a new signature, but then you're back in the
distribution problem I mentioned earlier with un-revoking whole keys.
Part of the design of OpenPGP is that subkeys are cheap - you should
be able to make new ones easily. In fact, there was a proposal for
perfect forward security in OpenPGP a few years ago that involved
generating new subkeys very frequently (even to the point of a new
subkey per message): http://www.apache-ssl.org/openpgp-pfs.txt
c) when I use a 0x30 certification revocation signautre.
Here the whole thing is different to a) and b) (as far as I understand).
The RFC says "This signature revokes an EARLIER User ID certification
signature..."
Does this now exactly mean,.. that it revokes ALL earlier user id
certification signatures?
Not exactly - it revokes one signature. However if there is more than
one signature, the earlier signature should be superseded by the later
one.
And what does this now mean for my idea on how to force an
implementation to use only the most recent signatures?
Will the following work, as long as the signature creation times are
correct? And I mean would it be correct even when strictly following
the RFC?
Public Key
UID1
0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30
below)
UID2
0x13 signature on that user ID (timestamp 1)
0x13 signature on that user ID (timestamp 2)
0x30 revocation (timestamp 3) (revokes every
0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE
timestamp 3
0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30
above)
This will work in GPG, but I don't think it is necessary - the same
thing would happen even if you removed the revocations (Note,
though, that you can't have a 0x1F on a UID. 0x1F is a direct key
signature and is not issued on a UID).
David