Malformed Revokation Certificate?

[John Clizbe]

David Shaw wrote:
> On Aug 8, 2012, at 5:24 AM, Jay Litwyn wrote:
> 
>> On 2012-08-08 2:20 AM, Peter Lebbing wrote:
>>> On 07/08/12 15:18, Jay Litwyn wrote:
>>>> I submitted this revokation certificate to a couple of servers and 
>>>> they said it was malformed, and I had trouble guessing how to
>>>> generate anything different. So, I imported the revokation
>>>> certificate, exported the whole key, and submitted that. It worked.
>>> Now, I haven't ever revoked a key, but I wouldn't be surprised if this
>>> is how it is supposed to work. After all, the revocation certificate is
>>> just a special type of signature. You don't upload signatures to a
>>> keyserver, you upload keys with signatures to a keyserver. The
>>> keyserver then merges in all the signatures it has on that key.
>> As long as the signature names what it signs, I do not see why a 
>> revokation certificate should not work on its own. It does when I import
>> a revokation certificate to my own key.
> 
> A revocation certificate is a bare certificate, not attached to the key
> that it revokes.  This is an extension to the spec that GnuPG implements
> (as it is easier to save/print/archive a bare certificate).  If you want
> the keyservers to accept them, you need to talk to the keyserver folks.  As
> this is an extension, they aren't required to support it.

As it is an extension, we don't. SKS also does not recognize the CA
certification on X.509 certificates converted to OpenPGP by PGP. I haven't
checked with GnuPG 2, but GnuPG 1.4 doesn't recognize the CA certification on
those keys either.

Uploading a bare revocation certificate currently fails with an Add Error.
Kristian has modified this for the next release to be a more informational
message:
    "Add failed: This is a stand-alone revocation certificate. A revocation
    certificate should be imported to the respective public key before being
    published to a keyserver"

> Alternately, if you set any of the PGP compatibility options (--pgpX) in
> GnuPG, it turns off the extension and outputs a public key along with the
> revocation certificate, ready for directly sending to keyservers.

Another alternative is to work the desired behavior into the standard. For
example, the present SKS development trunk supports Elliptic Curve Public keys
(ECDSA, ECDH) which are an extension to RFC 4880 contained in RFC 6637.