The comp.security.pgp FAQ

Assuming that you selected a good solid random pass phrase to encrypt your secret key ring, you are probably still safe. It takes two parts to decrypt a message, the secret key ring, and its pass phrase. The secret key is encrypted with the passphrase before it is stored in the secret keyring.

Assuming you have a backup copy of your secret key ring, you should generate a key revocation certificate and upload the revocation to one of the public key servers. Prior to uploading the revocation certificate, you might add a new ID to the old key that tells what your new key ID will be. If you don't have a backup copy of your secret key ring, then it will be impossible to create a revocation certificate under the present version of PGP. This is another good reason for keeping a backup copy of your secret key ring.

As Phil Zimmermann put it: "I'm sorry, you're hosed."
You can't, since the pass phrase is required to create the certificate. You must decrypt the secret key to sign the revocation statement, and for that you need your pass phrase.

The way to avoid this dilemma is to create a key revocation certificate at the same time that you generate your key pair. Put the revocation certificate away in a safe place and you will have it available should the need arise.

The easiest way to do this is:

1. Make a backup of your public and secret keyrings.
2. Revoke your key with pgp -kd youruserid.
3. Extract the revoked key to a file with pgp -kxa youruserid. This file is what the manual calls the "revocation certificate."
4. Store the certificate in a safe location, for example on a floppy which you keep someplace else.
5. Restore the backed-up keyrings.

This is a very tricky situation, and should be avoided at all costs. The easiest way is to prepare a key revocation certificate (See 7.3 for details on how to do this) before you need it, so you can always revoke the key, even without the secret key.

Alternatively, you can use a binary editor to change one of the user IDs on your public key to read "Key invalid; use key 0x12345678" or something to that effect. Keep in mind that the new user ID can't be longer than the old one, unless you know what you are doing. Then extract the key, and send it to the keyserver. It will think this is actually a new user ID, and add it to your key there.

However, since anyone can do the above, many people will not trust unsigned user IDs with such statements. As explained in question 6.3, all user IDs on your key should be self-signed. So again, make a key revocation certificate in advance and use that when necessary.