This is by no means a comprehensive guide. It is not even a beginner’s guide. However, this text should be a reasonable walkthrough for the expectations before, during and after the signing party.

Thank you in advance for your interest!

Preparing your key

You should have a GPG key prepared in advance. For purposes of this party, your master key should be at least 2048 bit RSA (highly recommended 4096 bit RSA) and should include all the identities (email addresses) you plan to use and wish to have signed.

It’s recommended that you use your master (or primary) key only for certifying your key’s subkeys and other people’s keys. It’s also recommended that you strip out your master key, and store it offline.

If you are creating a new master key, a good tutorial will include descriptions on how to make your new master key capable only of certifying your key’s subkeys and other people’s keys.

gpg --expert --gen-key
# choose 8 "RSA (set your own capabilities)" to be able to pick capabilities.
# turn off signing and encryption capability, leaving only certify capability. 
# because this is your master key, choose 4096 bit keysize

When generating a GPG key, choose sensibly long, but not too distant expiration time. You can extend duration of your key later, and if you lose control of your key, you will not regret having a non-expiring key around. (You simply update the expiry locally, and upload the refreshed public key to the keyserver.)

Add subkeys for signing and encryption using gpg --expert --edit-key chosen@email.address (or, instead of the email address, use the key ID), then entering the addkey command. Subkeys should also have reasonable expiry times.

Add user IDs for each of the email addresses you want to get signed at the party. Use the adduid command.

Once you’re done, use the save command.

You’re also recommended to have a secure passphrase on your key and subkeys. Passphrase-protected keys and subkeys remain passphrase-protected even when exported.

All these steps and more (generation of revocation certificate, information on backing up the secret/private keys, uploading public key to a keyserver, etc) are documented in the above-linked tutorial. It also includes information on how to remove the master key’s secret key from your keyring, which should be done on laptops et al, based on your level of concern. Before following the information on deleting the keys from your daily-use storage, be sure to back up ~/.gpg folder, so you do not accidentally erase your only copy of the master key.

What to bring to the keysigning party?

Print out a piece of paper containing your GPG key’s fingerprint. Preferably, print out several pieces of paper with your fingerprint and name on it, so participants can keep a copy.

gpg2 --fingerprint | grep fingerprint
      Key fingerprint = 192F B8E8 72B5 4B17 5FB8  6EBF 9A3B 99C8 8F9E 89D5

Note that the ID for the above key is 8F9E89D5 – the last 8 hex digits of the fingerprint.

If you do not print out a piece of paper, have a way of obtaining the fingerprint that you are reasonably sure is not compromised.

Please also upload the key to keyservers keys.gnupg.net and pool.sks-keyservers.net. Use gpg --keyserver key.server.here --send-keys 0x8F9E89D5 to do this.

Verifying identities

When handed the piece of paper, request to see the other person’s photo ID — e.g. national identity card, passport, or driver’s license. Based on that, judge whether you are satisfied with proof of identity and accept the piece of paper or not.

In case the other person does not have a piece of paper to provide you with, be prepared to collect and securely store the fingerprint yourself.

Signing the key

Once you reach the machine where you have your master key, take the list of fingerprints and names you collected. Obtain the keys from keyservers using gpg --keyserver key.server.here --recv-keys 0x8F9E89D5. Verify that the key fingerprint matches — use gpg --fingerprint 0x8F9E89D5. Using the same output, verify that the identities (email addresses and names) match to what you agreed to sign.

Then sign the key using gpg --sign-key 0x8F9E89D5.

Sharing the signature

You could upload the newly signed public key to the keyserver, but probably should not. This is because sending the signature encrypted to the email addresses listed in the key is a good way of verifying email address ownership. Only a person that owns the key you signed will be able to decrypt your signature, and only a person that owns the email address will be able to receive the encrypted key in the first place.

gpg --armor --output 00AA11BB-signedBy-1A2B3C4D.asc --export 00AA11BB
gpg2 --encrypt  -r identityone@domain.tld --armor 00AA11BB-signedBy-1A2B3C4D.asc
# send out 00AA11BB-signedBy-1A2B3C4D.asc.asc
rm 00AA11BB-signedBy-1A2B3C4D.asc.asc
gpg2 --encrypt  -r identitytwo@domain.tld --armor 00AA11BB-signedBy-1A2B3C4D.asc
# send out 00AA11BB-signedBy-1A2B3C4D.asc.asc
rm 00AA11BB-signedBy-1A2B3C4D.asc.asc

Alternatively, you could use your email client to more conveniently encrypt the entire email, not just the key.

This method shares signatures for all identities to all of the email addresses. If you wish to be more careful, and sign only one identity + email out verification for only one identity, please use this as a starting point.

Receiving signatures

It’s suggested that you use a GPG-enabled email client to receive and decrypt the incoming keys. Once you gpg --import the key into your keyring, you should publish the updated key by using gpg --keyserver key.server.here --send-keys.

Don’t forget to thank the person that signed your key 🙂