[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Series of minor questions about OpenPGP 4




On Jan 31, 2009, at 6:41 PM, Peter Thomas wrote:
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?

Section 11.1. But notice what that section is: Transferable Public Keys. This doesn't really mean you *can't* re-sign a subkey. It just means that once you *have* re-signed a subkey, you need to remove the old signature (and revocation, if any) before you give the key to anyone else.

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").

Subkeys aren't really usable for roles. User IDs make great roles. Subkeys can be used by anyone who cares to, so if you have two encryption keys, even though you intend one for "home" and one for "work", you have no way to tell me which one you want me to use, and even if you did, I could use the other one if I wanted to.

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 ;-) )?

The RFC specifies the signature target which lets a revocation indicate which signature is being revoked. Aside from that, there is no indication at all beyond that the revocation is issued over the same data as the signature being revoked, and that it is dated after the original signature. It's not most recent, it's not least recent, it's simply not specified.

David