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