Certification revocation -- identifying the revoked certificate

["Michael Young" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----

In the ensuing discussion of self-signature revocations, I didn't see an
answer to a fundamental question: what does one hash in a certification
revocation (type 0x30)?  The specification is explicit for all of the
other types, but not this one.

I skimmed the GnuPG source, and it would appear to hash the target key
and userID, and the usual trailing matter (including the hashed
subpackets from the revocation certificate, (*not* the original).
Is my reading correct, and is that what the specification intends?

I note that this does not identify *which* certification is being revoked,
if there is more than one.  If I created multiple signatures (with
different signature type, timestamp, or subpackets) for the same
key/name pair, I see no way to revoke just one of them.  Are multiple
signatures illegal?  (Clearly, multiple self-signatures are legal,
and the same problem comes up there, as per the recent discussion.)

This seems broken.  A certification revocation should identify the
original certification, and hash the same material as the original
(followed by the revocation certificate material).  The identification
is desirable, but not strictly required -- a receiver could test all
possible certifications.  It would seem that a new subpacket would be
in order.  The original contents are absolutely essential, though.

I suppose one interpretation might be that a revocation should match
an original that has *exactly* the same subpackets (except for the
"revocation reason").  How does this work for these things
[with my guess as to an answer in brackets for each one]?
    v3 signatures, which use an explicit creation time instead of
     subpackets [use v3 revocation with same creation time];
    different signature types (e.g., "persona" vs. "casual")
     [do not permit distinction on this];
    other subpackets that might apply to both the original and the
     revocation (e.g., notation data) [there may not be any]; or,
    revocation of an earlier revocation (as Florian Weimer suggested
     might be valid for "no longer in use" reasons) [disallow this].
In any case, if this was the intention, the specification should say
so (and GnuPG should make it easier to generate an exact match :-).

I'm really not out to be pedantic here.  I think it really is important
to have clear rules for revocation.  If multiple certifications for a
key or key/name are to be allowed, or are the *recommended* way to
update preferences/qualities, then it is essential that a revocation
be able to target the proper one.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4wS9WNDnIII+QUHAQEUeQf+KTrpPoU8lviz/C+mn7wN34MGOG3WUqsO
MCfaVlpYAe+8Ga2nEzcOWoOak8hs13clc4dpHHRstdvFBpolYGd1M3z2HD+pjMG5
sVWMRUuJVc9uicjTqjWqzLSqTUVZ0LFP845gj56VVRYosg1iS1XT1APvdJMolTl6
umQqzRoHpVv+hwRhiJeclYBknSShBf05hHmGVBWlyOnRsPa/YjMyeLutqVVAAqT/
QvxWQs1zhE2cvRxrqNbwfXjcEmWY26CUM69XpZJGuemaCGDutmtxRMPgMpyaeLA/
odpwmJ8UG2MyyNWuRbQ62KrqtS2bXGCZPV3L8R6ipwhgs09R2IYCKw==
=hjzN
-----END PGP SIGNATURE-----