I did some more thinking over the issue of revocations and looked into the
source code of GPG to see what it does.
For one thing, key-uid and key-attribute binding revocations are exactly
identical to certifications, except for the signature type (0x30 instead of
0x10..0x13). It does not revoke any particular certification sig., but the
binding itself, like a negative assertion: "I certify that this
uid/attribute DOES NOT belong to the owner of this key".
David seems to be right about the fact that currently, there is no
distinction between key-revokers and certification revokers. However, since
this functionality is not it wide use yet, I would suggest to make the
following somewhat backwards-compatible change: The revocation key subpacket
authorizes revocations only for the subject of the certificate in which it
has been included. Thus, if it is a certificate directly on a key, it allows
the designated revoker to revoke the key. If it is in a key-uid binding
certificate, it allows the designated revoker to revoke that particular
key-uid binding. Alternatively, we could add a new subpacket type with this
semantics, and leave 184.108.40.206 as it is.
As for the revocability bit (as defined in 220.127.116.11), it only refers to the
author of the certification, being a committment by the signer. The standard
seems to be pretty clear about that. Its wording, however, makes one wonder
HOW signatures can be revoked, since the rest of the standard talks only
about revocations of keys and key-attribute/key-uid bindings, but not
signatures as such. I'd think, it merits some more discussion.
As for my own itch, I am increasingly confident that I will implement IOU
notes as attributes, much like photo IDs.
Description: Digital signature