[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Series of minor questions about OpenPGP 4
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@xxxxxxxxxxxxxxx> 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.
> 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?
> 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.)
> I mean the following doesn't work, right?
> Primary key
> |--->0x13 on that UID
> |--->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
> |--->0x13 on that UID2
> |--->0x18 on that subkey2
> But the whole thing would still be revoked, 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
> 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
> 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
> 0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below)
> 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).