Revoking a certificate in GPG4Win -- does this feature exist?

I am testing certificate revocation with another tester who is running BSD Unix (Open Source).

He is able to send me .ASC files which I can import into Kleopatra that revoke his key. But I cannot seem to find such a feature in GPG4Win that allows me to revoke one of my older keys (certs).

Would be grateful for any tips or hints.

Thank you.

Hi Ramon,

Yes, you can revoke a key with GPG4Win. But, as far as I know, you will have to use the command line to generate a revocation certificate.

To do this, open a command prompt (if you’re not familiar with how to this, you can type “command prompt” in the Windows search box, or hold the Windows key and press “R” and then type “cmd” in the run box.)

At the prompt, type:

gpg -o --gen-revoke

…where is the name of the file you want to save the certificate to, and is the ID of the key you want to be able to revoke. You can also use the “-a” switch to generate the file in ASCII instead of binary. So, for example, typing:

gpg -a -o revoke.txt --gen-revoke ABCD1234

…will generate a revocation certificate for key ABCD1234 and the file will be named “revoke.txt”. You can use the ID of the key or any subkey you would like to individually revoke.

GPG will ask if you are sure you want to do this and will ask if you want to specify a reason. (If you don’t want to give an “optional description”, just hit “Enter” at the prompt.) It will also ask you for the passphrase for the key. The revocation certificate will be stored in whatever directory the command prompt is at when you create it. This is usually “C:\Users\YourUserName” by default.

To actually revoke the key, simply import the file as you would any key, or upload it to a key server. Make sure to keep the file in a safe location, though. As GPG will warn you, anyone who has access to it will be able to render your key useless. Once a key is revoked, it cannot be restored.

You will also want to make sure that everyone has an updated copy of your PUBLIC key so that they do not continue to use the revoked key. However, you should still be able to decrypt messages which were encrypted with the revoked key.

Hope that helps!

Regards,
Sean C.

My sincerest thanks – your reply is very professional and helpful, and I have learned many new aspects of GPG4Win.

Best regards,

Hello,

I am learning about PGP4Win and have a few basic questions.

I am curious about the revocation process. I read your response to Ramon, which is very helpful. I’d like to follow up with some clarification questions.

You wrote:

gpg -o --gen-revoke

…where is the name of the file you want to save the certificate to, and is the ID of the key you want to be able to revoke. You can also use the “-a” switch to generate the file in ASCII instead of binary. So, for example, typing:

gpg -a -o revoke.txt --gen-revoke ABCD1234

I am not clear on the terminology. Is the “key” the file. For example, if I have a public key as User1.asc and a private key as User1Secret.gpg, could I use the following command to generate a revocation certificate? (The secret key was generated by using Kleopatra, right mouse clicking on my certificate, and then choosing “Export Secret Keys”.)

gpg -o User1SecretKeyRevoke.gpg --gen-revoke User1Secret.gpg

Would that work?

Also, on a different website, it mentioned the following:

http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-key-revocation.html

Assuming you have a key revocation certificate previously made (or a backup copy of your secret key ring with which you can generate one now), 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 (or at the very least generate a revocation certificate).

I would like more clarification on “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.” Can you please elaborate on that statement? In particular, what is the new ID and how do I add it to the old key?

Thank you.

Best regards,
Kevin

Hello,

I solved one of my questions. I used the following command successfully:

gpg -o User1SecretKeyRevoke.gpg --gen-revoke A1B2C3D4

where A1B2C3D4 is the Key-ID found in Kleopatra. Although I didn’t use the -a switch, the file User1SecretKeyRevoke.gpg was about 1 kb in size and seems to contain ascii characters. Please confirm that I have done everything correctly.

I am still curious about second part of my prior message:

I would like more clarification on “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.” Can you please elaborate on that statement? In particular, what is the new ID and how do I add it to the old key?

Thank you.

Best regards,
Kevin

Hi Kevin,

It looks like you correctly generated a revocation certificate for your key. It seems that you do not need the -a switch, the revocation certificate is generated in ASCII automatically. If you open the file in a text editor and at the top it says:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: A revocation certificate should follow

…then you have done everything right.

In regards to your second question: the reason this is suggested is as a type of security measure. Let’s say you revoke a key, and then generate a new one. At the same time, someone else generates a key and puts your name on it with their email address. Now, if someone imports or refreshes your old key, they will see it is revoked. If they search for your new key, they may inadvertently import the wrong key and send sensitive information to the wrong person. However, if your old key has a message that contains the ID of your new key, that is one indication that they are importing the right new key. The new ID is that message. (Note that if your old SECRET key is compromised [stolen], then this security measure is not to be trusted. The ONLY way to be 100% sure, in any case, is to get the key directly from the owner.)

Now, how to do it: in Keopatra, under the “My Certificates” tab, highlight the key to which you want to add an ID. Click the “Certificates” menu and select “Add User ID”. Fill in the appropriate information. You probably want to add the new key ID to the comment line, something like: “My new key ID is ABCD1234”. Click “Okay” and you should get a message that the new ID has been added. You can double-click the key to see the new ID displayed with the key info.

If you want to use the command line, first you need to enter the key editing mode by typing:

gpg --edit-key

…where is the ID of the key you want to edit. You will now have a new prompt: “gpg>”. At this prompt, type:

adduid

GPG will ask for a name, email and comment. Unlike Kleopatra, none of the fields will be auto-filled, you will have to enter them manually. One other difference is that, when using the command line, you do not have to include an email address - you can just hit “Enter” to skip that line. When you are done, gpg will ask if you want to change anything, accept what you have [(O)kay] or discard the info [(Q)uit]. If you choose “(O)kay”, you will be back at the “gpg>” prompt. Now, you must type “save” to save the changes. If you type “quit”, GPG will ask if you want to save the changes you have made, anyway.

The last step will be to distribute the revoked key with the new ID and your new key. Then, notify all of your contacts that your key has changed. And that’s it! Of course, if you’re just revoking a subkey you won’t need to do any of this, because the new subkey will be attached to your old master key. You just have to update your key on any keyservers it’s on and notify your contacts. Anyone importing or refreshing your key will automatically get the new subkey and see that the old subkey had been revoked. GPG (and GPG4Win) will not use a revoked subkey.

For a partial list of commands that can be used with the command line, simply type “gpg --help”. (You can also type “help” at the “gpg>” prompt for commands specific to key editing.) For a full list of commands, see: https://www.gnupg.org/documentation/manuals/gnupg/Option-Index.html#Option-Index

Regards,
Sean C.

Hello Sean,

Thank you very much for your detailed reply. This material is completely foreign to me, so I am trying to understand as much and as quickly as possible. I greatly appreciate your patient and detailed responses.

Below I will quote some portions to ask follow up questions or provide comments.

My understanding of the keys and how they work is not strong.

Now, how to do it: in Kleopatra, under the “My Certificates” tab, highlight the key to which you want to add an ID. Click the “Certificates” menu and select “Add User ID”. Fill in the appropriate information. You probably want to add the new key ID to the comment line, something like: “My new key ID is ABCD1234”. Click “Okay” and you should get a message that the new ID has been added. You can double-click the key to see the new ID displayed with the key info.

If I understand correctly, the process is as follows:

a) Generate a new key (called “NewKey”) and note the “Key-ID” listed in Kleopatra.

b) Upload NewKey to the server.

c) Highlight my Original Key (called “OriginalKey”) in Kleopatra, and then follow your process described above to insert the new “Key-ID” in the comment field.

d) Do I then re-export my OriginalKey to the servers so that the information with the note for my NewKey is available to all?

e) Would I then re-create my Revocation Key for the OriginalKey and upload it to the server, too? My Revocation Key allows for some comments, too. Are those comments visible to all? I believe I should provide the same NewKey Key-ID in the comments here, too.

f) After having uploaded the Revocation Key to the server, does my OriginalKey completely disappear from the server at some point?

In essence, I am trying to understand the complete process of how to revoke my Original Key and what happens to my OriginalKey. As discussed, I understand how to create a Revocation Key, though I am not clear on the process and the end result. By the end result, I am not sure if the old information remains visible or if it is removed.

You discussed using the command line in place of Kleopatra. Being new to GPG, I am inclined to use Kleopatra for as much as possible and will use the command line when necessary. For example, I need to use the command line for creating a Revocation Key.

You wrote:

The last step will be to distribute the revoked key with the new ID and your new key. Then, notify all of your contacts that your key has changed. And that’s it! Of course, if you’re just revoking a subkey you won’t need to do any of this, because the new subkey will be attached to your old master key. You just have to update your key on any keyservers it’s on and notify your contacts. Anyone importing or refreshing your key will automatically get the new subkey and see that the old subkey had been revoked. GPG (and GPG4Win) will not use a revoked subkey.

This largely speaks to process I described above where I am not clear on the sequence of steps. Can you please comment or clarify the correct sequence of steps for someone who wants to replace their original key with a new one?

You mention a “subkey” and “master key.” I am unfamiliar with either term. I have just created one key so far. Can you please point me to where I can understand these terms?

Sean, I am very appreciative of your efforts. I look forward to your comments.

Best regards,
Kevin

Kevin,

In your reply, a) through c) is correct.

In response to d), yes, you would need to update your old key on the servers to include the new UID (with the note).

Regarding e), I must admit I’m not entirely sure about this. I believe an old revocation certificate would still work, but it couldn’t hurt to make a new one, anyway. As for whether the revocation comments will appear on the server: I don’t think so. In fact, I just did some testing and I don’t see the revocation comments displayed anywhere. It makes me wonder what purpose they serve.

In response to f): no, any key uploaded to a server will likely remain there forever. The reason is twofold: first, the keyservers don’t automatically delete keys, even if they’ve been unusable for a long time. Second, most keyservers belong to a network of keyservers. These servers “talk” to each other and share information. If you delete a key from one server, it will soon get that key back from another server. This communication is happening constantly. So, in order to successfully delete a key, you would need to find all of the servers in the network and delete the key from all of them simultaneously. That is practically impossible. This is a good thing, really, because it ensures that anyone refreshing your old key in the future will see that it has been revoked.

In summary, the steps for creating a new key would be:

  1. Generate a new key and note the ID.
  2. Add a new UID to your old key containing a note indicating the ID of your new key. (Note that although this is recommended, it is not mandatory and should not be the sole source of trust.)
  3. Revoke the old key and update it on a server if you use one. (Note that a revocation certificate can usually be uploaded directly to a keyserver.)
  4. Upload the new key to the server. (Note that it doesn’t really matter in which order you do steps 3 & 4.)
  5. Notify your contacts that your old key has been revoked and that a new key is available. (You can send it to them directly or have them get it from the server.)
  6. Done!

There is one extra security measure you can take: you can sign your new key with your old key. This will show anyone importing the new key that it was indeed generated by the holder of the old key. Just like the new UID on the old key, this is really only trustworthy as long as the old key has not been stolen. To do this in Kleopatra, highlight the new key, click the “Certificates” tab and select “Certify Certificate”. In the dialogue that pops up, click the check box next to your new key and the checkbox that says “I have verified the fingerprint”. In the next dialogue, select your old key and click the button next to “Certify for everyone to see”. (It’s up to you if you want Kleopatra to send it to the server for you.) This is also not mandatory and should not be the sole source of trust. If your old key was compromised and the attacker had your password, they could generate a false key, add a new UID to your old key and sign their false key with your old key. THE ONLY WAY TO BE 100% CERTAIN IS TO GET THE KEY DIRECTLY FROM THE OWNER!

Now…subkeys: this is where things can get a little complicated. Subkeys are keys that are subordinate to your main key. They can be created and revoked independently from your main key. By default, when you create a key with Kleopatra, you get a main key and one subkey. The main key can certify, encrypt and sign. The subkey can encrypt. You can change what the keys do with the “Advanced Settings” during key creation, but your choices are somewhat limited. Using the command line, you can get really specific with the number and type of subkeys and the capabilities of the main key. This is useful if you want to create a new encryption or signing key, but you don’t want to revoke your main key. This way, whenever someone refreshes your key, they will automatically get your new key without having to import an entirely different key. Also, any signatures attached to your main key will not be lost. Another advantage of this setup is that you can export only your secret subkeys, and keep your main key off of your computer entirely. So, if your keys are on a laptop and the laptop gets stolen, you will still have your main secret key and you can revoke your subkeys and generate new ones. If you’re really interested in learning more about how to do this, there is an excellent article about it here:

https://alexcabal.com/creating-the-perfect-gpg-keypair/

I hope all of that made sense. Unfortunately, good security is inherently complicated. Feel free to ask for more clarification on anything.

Regards,
Sean C.

Hello Sean,

It’s interesting that the revocation comments do not seem to play a role, at least not one that we can see.

I am disappointed to learn that once our information hits the servers, it’s there forever. I expected that the key servers would behave a similar fashion to the internet servers. That is, once the DNS data has been changed or domain name has been deleted, the servers would incorporate the new information by either updating the DNS stuff or dropping the domain altogether. I would have expected the key gpg data to be timestamped, so the servers could coordinate the information without overwriting previously deleted information. Still, your response is helpful.

Out of curiosity, what happens if the certificate expires? Does it disappear then? If so, could one change an expiry date to the next day, re-upload it, and then have it disappear from the server once the expiry date has passed?

Thank you for providing a good summary on creating a new key and deleting the old one.

Your Step 3 caused me some grief because I don’t know how to use my revocation certificate. Out of curiosity, I used Kleopatra to open my revocation certificate. The good news is that it worked–my certificate was revoked. The bad news is, my certificate was revoked.

When I opened my revocation certificate using Kleopatra, I had expected a warning message or to see the revocation certificate on a separate line. Instead, there was NO warning. Just boom–existing certificate was gone.

So I had to discover a way to restore my certificate. Here’s the steps that I followed:

  1. Import my saved Private Key. Kleopatra says that the Key has been revoked.
  2. Take note of the Key-ID
  3. Delete Key from Kleopatra by selecting it and then deleting it.
  4. Using the command line prompt:
    4a) gpg --expert --delete-key Key-ID
    4b) Confirm by pressing: y
  5. Import my saved Private Key again. Kleopatra is happy with it; however, OwnerTrust was changed.
  6. I increased the trust level to “Ownertrust” to “Ultimate.” I believe I right mouse clicked on the certificate and hit “Certify Certificate,” or I used one the commands under the “Certificate Menu.” Somehow I managed to restore the Ownertrust level to “Ultimate.”

I used the following website and looked at the “answer” for some guidance.

http://superuser.com/questions/608336/un-revoke-pgp-key

My process differs somewhat. So if my process doesn’t work for others, they can try the “answer.”

Now that I restored my revoked key, my question is:

** How do I send my Revocation Certificate to the key server?

Switching to the next topic, I like your suggestion of signing the NewKey with the OldKey. That’s clever.

You stated, “THE ONLY WAY TO BE 100% CERTAIN IS TO GET THE KEY DIRECTLY FROM THE OWNER!”

The New York Times publishes their Fingerprint for confidential news tips. Please see here: https://www.nytimes.com/newsgraphics/2016/news-tips/

Interestingly under the email section, they call the Fingerprint a “Key.” However, when you search for the New York Times on the key server, you can verify that you have the correct Public Key because its fingerprint matches that of their webpage’s fingerprint. While not getting the key directly from the New York Times, you should be confident that the key is legitimate because of the fingerprints match. I believe we’re saying the same thing–that is, verify from the source that the key is valid.

Incidentally, browsing through this New York Times page piqued my curiosity and led me down this rabbit hole of wanting to understand PGP encryption.

Our last topic is subkeys. I read through your paragraph and very superficially skimmed Alex Cabal’s site. I do plan to go back soon to Cabal’s site for a more thorough read. I like the idea of having a “backup plan” in case your computer is stolen or lost. Perhaps another way to mitigate problems with a stolen or lost computer is to encrypt your entire computer using BitLocker. With BitLocker, the thief is presumably unable to use your computer.

You mention, “They can be created and revoked independently from your main key. By default, when you create a key with Kleopatra, you get a main key and one subkey.”

When I created a “key,” I created one public and one private key. I am not sure about a subkey. Can you please elaborate a bit further?

Thank you very much Sean for your patience and assistance. I look forward to your responses to my comments and questions. I believe I am getting close to obtaining a reasonable understanding of how to use PGP encryption.

Best regards,
Kevin

Kevin,

Very smart of you to keep a backup of your private key! You have learned firsthand one reason that is a good idea. :slight_smile: GPG/PGP forums are full of unfortunate souls who have accidentally deleted keys or forgotten passwords and have received the very bad news that they are “out of luck”. A key component of good security is not having a ‘back door’ - otherwise it could be exploited by an attacker. The downside is that if you make a mistake like this, you too are locked out! (In hindsight, I probably should have warned you about that. Sorry.)

I’m a little confused by your solution, though. When deleting a key using Kleopatra, it shouldn’t be necessary to delete it again using the command prompt. Kleopatra should delete both the public and secret keys simultaneously. As for how to send your revocation certificate to the server, it’s basically the same process as uploading a key. You have two options: you can revoke the key locally (which you found out how to do when you imported your revocation certificate in Kleopatra), and then re-upload your [now revoked] key to the server. Or, you can upload the revocation certificate itself directly to the server. The only way I have interacted with keyservers is through web pages, so I admit I’m not exactly sure if it is possible to send a revocation certificate directly from GPG or Kleopatra. On a web page (such as http://pgp.mit.edu/), you simply copy and paste the entire contents of the revocation certificate and hit the “Submit” button. The server will figure out which key it belongs to and revoke it on the server. In any case, sending a locally revoked key to a server will get the job done.

As a side note, you actually don’t have to generate a revocation certificate to revoke a key as long as you still have access to the secret key. You can use the command line to do it directly by entering the key editing mode and using the “revkey” command. But, generating a revocation certificate is still a good idea in case you lose access to the key.

Regarding expired certificates on keyservers: no, even then they will not disappear…ever. Once a key is on a keyserver, it’s there forever. Unless, of course, the keyserver itself is taken down. But then, the key will still be on all of the other keyservers that were in communication with that server. (I do know of at least one server which allows you to delete a key [the “PGP Global Directory” at https://keyserver.pgp.com/vkd/GetWelcomeScreen.event]. But that is a rare exception.)

Regarding trust: this all comes down to what level of security you are comfortable with. Sure, the web page you were on lists a key fingerprint. But, can you be 100% sure that the web page itself is genuine? Spoofing is not an uncommon tactic. Many attackers exploit things like “fat finger” typing and spelling errors. For example, a malicious person might register a domain called “newyorktimes.com” (instead of “nytimes.com”) or even “nytims.com” or “nytimed.com”. Then there’s DNS spoofing - even if you get the domain name right, you might be re-directed to the wrong page. These spoofed pages may look EXACTLY like the genuine article…the only difference being a small thing, like a different PGP key fingerprint. In other words, THE ONLY WAY TO BE 100% CERTAIN IS TO GET THE KEY DIRECTLY FROM THE OWNER! :wink:

Regarding subkeys: think of the main key as your identity. It’s key ID is what people associate with you and it is what they sign (certify), saying that they trust this is your key. The main key is also the only key which can certify (or sign) other keys. Keeping the same main key ID makes maintaining a “web of trust” simpler. Subkeys are attached to your main key and can do the actual work of encrypting, signing (or authenticating to an SSH server). Subkeys cannot be added to or revoked from the main key without access to the main secret key AND the passphrase, so if someone trusts your main key, they also trust your subkeys. When you create a key pair, the encryption subkey is most likely the one which is actually used to encrypt messages to you, even if the main key also has the ability to encrypt. If, in the future, you want to create a new encryption key (such as if you want to go from a 2048 bit key to a 4096 bit key), you can revoke the encryption subkey and create a new one. This way, you don’t have to revoke your main key, you won’t lose any signatures and you won’t have to jump through the hoops associated with distributing an entirely new key. Your contacts will still be able to associate your old key ID with you. You just have to make sure they have the latest version.

Every key has a public and private part, regardless of whether it is a main key or subkey. Private signing subkeys are used to make signatures, public subkeys are used to check them. Public encryption subkeys are used to encrypt messages, private subkeys are used to decrypt them. If you double-click your key in Kleopatra, a window will open showing the key details. If you click on the “Technical Details” tab, you should see two entries. Those are your main and sub keys. The first one in the list should be the main key, and the last eight characters in the “ID” field of that key should correspond to your main key ID. The second one is the subkey, which is probably the key doing all of the encrypting of messages sent to you. You can add (addkey), remove (delkey) or revoke (revkey) subkeys using the command prompt in key edit mode. (Just be sure to select the proper subkey before revoking or deleting.) The --expert switch will give you more control over the characteristics of a new key.

Regards,
Sean C.

Hello Sean,

No need to apologize with respect to precautions for the revocation key. If I didn’t have the private key backed up, I would have been much more cautious. As far as my passphrase is concerned, it is hopelessly long and hopelessly random. It’s backed up to password programs.

With regard to my solution, you mention that it shouldn’t be necessary to delete again using the command prompt after using Kleopatra. I agree, that’s the intuitive solution. I am reasonably confident, however, I tried that immediately and it failed. So let’s revise the process.

  1. Import my saved Private Key. Kleopatra says that the Key has been revoked.
  2. Take note of the Key-ID
  3. Select and delete Key in Kleopatra.
  4. Import my saved Private Key. If there is no warning message from Kleopatra saying that the Key is revoked, you’re done. Stop.
  5. Assuming Step 4 failed, because Kleopatra is still warning that the Key is revoked, delete Key from Kleopatra by selecting it and then deleting it.
  6. Using the command line prompt:
    6a) gpg --expert --delete-key Key-ID
    6b) Confirm by pressing: y
  7. Import my saved Private Key again. Kleopatra is happy with it; however, OwnerTrust was changed.
  8. I increased the trust level to “Ownertrust” to “Ultimate.” I believe I right mouse clicked on the certificate and hit “Certify Certificate,” or I used one the commands under the “Certificate Menu.” Somehow I managed to restore the Ownertrust level to “Ultimate.”

Thank you for the heads up on using the command line to create a revocation key. And, thank you for providing the webpage to paste the revocation certificate into. For the benefit of others, you provided: http://pgp.mit.edu/.

I found the PGP Global Directory (https://keyserver.pgp.com/vkd/GetWelcomeScreen.event) interesting because when I searched for my key using my name and then my email, but failed to turn up anything. So I went back to Kleopatra and used its “Lookup Certificates on Server.” It found my information without difficulty. Do you know why the PGP Global Directory failed completely? Even just using my last name, I got nothing. Which I found odd.

Thank you for your information on regarding subkeys. Yes, I did click on the “Technical Details” tab to see both entries. You’ve increased my understanding. I still have on my “to-do” list to read Alex Cabal’s website.

Thank you, again, for all your help. I look forward to your comments.

Best regards,
Kevin

Kevin,

The PGP Global Directory is different than most other keyservers. As far as I know, it is not networked with any other servers. This is probably why one can delete a key on this server; it won’t simply reappear when the server communicates with a network. This also means that, in order for your key to appear on it, you must upload your key directly to that server.

Also unlike most other servers, the PGP Global Directory will attempt to verify that the uploaded key is indeed associated with the email address listed in the UID. It does this by sending an email to the address. If the owner of the address confirms that the key belongs to them, the server will sign the key. The signature expires after a few months and another email is sent out, thus confirming that the key and address are still valid and active.

But, all this really tells you is that the owner of the email address is the owner of the key…not who that person really is.

Regards,
Sean C.

Hello Sean,

Thank you for all your help. You provided in-depth answers with thought and clarity.

I hope you and your family have a wonderful happy holiday season.

Best regards,
Kevin

You’re most welcome. Merry Christmas!

Sincerely,
Sean C.