[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 4:48 AM, David Shaw <dshaw@xxxxxxxxxxxxxxx> wrote:
>> 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,...

>> 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.
Wow,.. uhm could you please point me to the location that mandates this?

> Thus you cannot resign a subkey to un-revoke it.
Uhm what do you mean with this?

> 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.
Ok,.. uhm let me think. This would also mean, that it's not possible
to later change the properties of a subkey (e.g. preferred algorithms
or it's key flags) while all this IS possible for the primary key and
for UIDs, right?

> 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.
Yeah,.. the keyservers would prevent this.

> Part of the design of OpenPGP is that subkeys are cheap - you should
> be able to make new ones easily.
That's true, of course. But it could be annoying if people expect
particular (sub)key ids, as they're used to it (e.g. when using a
subkey for a special role like "work" or "home").

> 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)
Wouldn't this actually create new security problems? I'm by no means a
crypto-expert, but AFAIK the more one uses a key to sign/encrypt data,
the more it is likely that someone can use all this data for
statistical attacks.
And this would be especially bad for the primary key, as far as I understand?

>> 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.
I must apologize myself,.. but I don't understand this.
The RFC must somehow specify which of the earlier self-signatures is
revoked by it, or not? Or does it always revoke the MOST RECENT found
signature BEFORE its own timestamp? If so where is this specified (I'm
just curious, not that I wouldn't believe you ;-) )?
And if that's the case we must remember that an implementation is
allowed to use any self-signature, it's just RECOMMENDED to use the
most recent.
This would mean the following:

Public Key
User ID
0x13 timestamp 1
0x13 timestamp 2
0x30 revokes the 0x13 from timestamp 2


Public Key
User ID
0x13 timestamp 1
0x30 still revokes the 0x13 from timestamp 2
0x13 timestamp 2

but now it's effectively as if we'd just have:
Public Key
User ID
0x13 timestamp 1

(isn't this what gnupg does when doing a minimize? removing all
unusable signatures?)

And even if not actually removed, an implementation would now be
allowed (as far as I understand the RFC) to use the 0x13 from
timestamp 1? Ok gnupg doesn't do this like this, as you explained in
that (sig+sig+revoc) example before, but other could.

I think I become mad ^^

> This will work in GPG, but I don't think it is necessary -
Sorry when I'm nasty, but just think of the example directly above
this text? Or the other examples I gave (with the older self-signature
using MD5 and the new SHAsomething, or other differing subpackets).
Of course probably any reasonable implementation will follow the
recommendation and just use the most recent self-sig like gnupg does
(sig+sig+revoc), but others might not.

What's the opinion on the others on this?

> the same thing would happen even if you removed the revocations
Ok but for this we have the keyservers... (thank god) ^^

> (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).
Oopps,.. of course,.. that was a typo ;-)

Thanks again in advance,