Keysigning party/After the party

Some after-parties are more glorious than others.

Note that I'm merely describing how you could do things, not how you should do things. Feel free to deviate from the advice if you like.

Using caff

Installation

Debian

For Debian, install the signing-party package from stretch/testing or sid/unstable, and install the dependency libmd0 from stretch or sid. The other dependencies can be met from jessie/stable. The caff from jessie is rather old, but is still usable, I think.

If you're using stretch or sid (sid? Really?), just install the signing-party package.

If you're using jessie/stable, add the following to /etc/apt/sources.list:

deb http://ftp.debian.org/debian/ stretch main
deb http://ftp.debian.org/debian/ sid main

And add the following to, for instance, /etc/apt/apt.conf.d/80local:

APT::Default-Release "stable";

If you now issue an apt-get update, your system will know about the packages in stretch and sid, but because you set a Default-Release, it will not install packages from these distributions by default.

Using either apt or aptitude (I prefer the latter, in visual mode), do the following:

apt-get install signing-party/stretch libmd0/stretch

This will install these two packages from stretch/testing and satisfy all other dependencies using jessie/stable.

Other distro's / OS's

Please extend this page with information if you know how to do this. You will need to create a wiki account to change pages.

Configure caff

Personally, I'm using GnuPG 2.1.16 on my jessie machines, but caff will detect your version and adapt to it. If you have previously used caff but have since made changes to your GnuPG setup, I'd recommend wiping ~/.caff/gnupghome (keep a backup for reference) to have it newly created by caff based on your current setup. Also check your ~/.caffrc for things not applicable to your new setup.

If you invoke caff once, without arguments, it will create a .caffrc for you. Edit it (read the man page for the options). Mine looks like:

$CONFIG{'owner'} = 'Peter Lebbing';
$CONFIG{'email'} = 'peter@digitalbrains.com';
$CONFIG{'gpg'} = 'gpg2';
$CONFIG{'keyid'} = [ qw{AC46EFE6DE500B3E} ];
$CONFIG{'also-encrypt-to'} = [ qw{AC46EFE6DE500B3E} ];
$CONFIG{'mail'} = 'yes';
$CONFIG{'also-lsign-in-gnupghome'} = 'auto';

In reality, I also have:

# By default the envelope-from is peter@tweek.lucas.digitalbrains.com, so I suppose this will do instead
$CONFIG{'mailer-send'} =  [ 'sendmail', '-f', 'peter@digitalbrains.com', '-t' ];
# $CONFIG{'bcc'} = 'peter@digitalbrains.com';

These are only needed if you have an odd setup, which I do. The BCC line is commented out but helps to see how the mails turn out. This bit of configuration is frowned upon by caff, it suggests I should fix my MTA instead. Unfortunately, there's nothing to fix, it works as intended. Just not for this use-case.

For every key that caff presents to you caff can send the signatures to the e-mail addresses listed in the UID's. This serves two purposes. On the one hand, the recipient can decide themselves whether to publish your signature or not. On the other hand, it provides a basic level of verification that the e-mail address in the UID actually belongs to that person, because they need to be able to receive your mail to publish your signature to the world. Since caff also encrypts the mail, they also need the private key to decrypt it.

I suggest you let caff perform this mailing task; the configuration above has it enabled. It will also make a local signature in your normal GnuPG keyring. This means that even if the recipient chooses not to upload your signature, you will still benefit from the local signature yourself. These local signatures are not uploaded to the keyservers, they only stay on your local keyring.

Sign keys

Take your stack of keyslips. You will need to verify the fingerprint on each one. Invoke caff with a list of the key ID's. For instance, my key ID is the "rsa2048/DE500B3E" bit on my key slip; just use the DE500B3E part. It's actually the last few digits of the fingerprint. Instead of listing all key ID's of everyone at the party in one caff invocation, put a few keyslips in front of you and invoke caff for those few. Handle them in order, discard them and get a few more. This just makes it easier to manage.

It might be necessary to first fetch the key from the place indicated on the keyslip. If there isn't any indication on the keyslip, it should be on the keyserver network, and caff will get it for you instead. If you need to fetch the key yourself, you can tell caff to get it from your normal GnuPG installation with the command line argument --keys-from-gnupg. Just do this for the keys not on the keyservers.

caff will launch GnuPG and default to signing all UID's. If there's more than one UID, GnuPG will ask if this is what you want; if not, just press Enter. Now you can check the UID's with the command uid, and for instance select UID 1 with uid 1. Continue with other UID's you want to flag (uid 2, uid 4, ...). Then type sign. An example of signing multiple but not all UID's can be seen here (note I used a key for which I have the secret key, so it'll be cosmetically different).

Regardless of whether there was only one UID to sign, you simply answered 'y' to Really sign all text user IDs?, or you selected your own set of UID's, now GnuPG will present you with a list of UID's to sign and the primary key fingerprint. First check the UID's match what is on the keyslip. Then compare all digits of the fingerprint on the keyslip to the digits on your screen. I hold the keyslip to the screen, that way the digits to compare are physically close to each other. If there is a difference, don't issue a signature. You're looking at the wrong key. First get the correct one, for instance by providing the caff invocation with a full fingerprint (no spaces).

If it's the correct one, sign it, and then type save. caff will continue to the next key.

If all goes well, caff will report that it is mailing out all the signed UID's.

Manually signing and sending keys

Take your stack of keyslips. You will need to verify the fingerprint on each one. You will need to provide GnuPG with key ID's. For instance, my key ID is the "rsa2048/DE500B3E" bit on my key slip; just use the DE500B3E part. It's actually the last few digits of the fingerprint.

Download keys

First, download all the keys from the keyservers:

gpg2 --recv-keys KEYID1 KEYID2 KEYID3 ...

If you notice GnuPG telling you multiple keys matched the short key ID, you will need to continue with either the long keyID or the full fingerprint from here on. The short key ID is the last 8 digits of the fingerprint and the long key ID is the last 16 digits of the fingerprint. Depending on your version of GnuPG, it might not like to see spaces in fingerprints. On my GnuPG 2.1.16, the following are all ways to specify my key:

gpg2 -k DE500B3E
gpg2 -k AC46EFE6DE500B3E
gpg2 -k 8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E
gpg2 -k '8FA9 4E79 AD6A B56E E38C E5CB AC46 EFE6 DE50 0B3E'

Sign keys

Then for each key ID:

gpg2 --edit-key KEYID

Look at the key ID's; if you want to sign all, just type sign. Otherwise you can check the UID's with the command uid, and for instance select UID 1 with uid 1. Continue with other UID's you want to flag (uid 2, uid 4, ...). Then type sign. An example of signing multiple but not all UID's can be seen here (note I used a key for which I have the secret key, so it'll be cosmetically different).

Regardless of whether there was only one UID to sign, you simply answered 'y' to Really sign all text user IDs?, or you selected your own set of UID's, now GnuPG will present you with a list of UID's to sign and the primary key fingerprint. First check the UID's match what is on the keyslip. Then compare all digits of the fingerprint on the keyslip to the digits on your screen. I hold the keyslip to the screen, that way the digits to compare are physically close to each other. If there is a difference, don't issue a signature. You're looking at the wrong key. First get the correct one.

If it's the correct one, sign it. I suggest you now type lsign and once again sign it with a local signature. The first "normal" signature is one that can be exported and sent to the keyserver. Conversely, a local signature doesn't get exported from your local keyring unless you explicitly force this. By keeping a local signature, you can benefit from that signature in your own Web of Trust even if the owner of the key decides not to share the signature you're sending them with the world.

Now type save, this saves your signature and exits gpg.

Send the key to the owner

It's time to send the key to the owner. Export your copy of their public key:

gpg2 -ao KEYID.asc --export KEYID

Then send them a mail with this KEYID.asc file included, either in the text or as an attachment. You don't need to send separate mails to separate UID's. This functionality of caff is not easily reproduced by hand. You could encrypt the file, though. This ensures that only the recipient can disclose your signatures. Here's how:

gpg2 -a --export KEYID | gpg2 -ao KEYID.asc -r KEYID -e

Yes, I'm explicitly doing ASCII armouring twice. When you send this via mail and put the .asc inside the mail body rather than use an attachment, the recipient's mail reader might include it as text in the mail body. This provides a nicer user experience for the recipient. And even as an attachment, the recipient might be confused about what the binary data is, whereas if they see -----BEGIN PGP PUBLIC KEY BLOCK-----, they'll probably understand.

(This text is copyright 2016, 2017 Peter Lebbing under the CC-BY-SA 3.0 licence)