They Geysigning program shall help the OpenPGP Keysigning process. Monkeysign exists which has a lot of potential. If we integrate it more, we might be able to create an easy to use tool.

The scenario I envision to cater for is very special: One person wants to sign another person's key while both of them are physically close (and on the same WiFi network). The tool, for now, shall make it easy in that scenario. We can think about extending it later. The scenario is deliberately simple and narrow. It shall stay that way until we have found a working way of dealing with keys, signatures, revocations, sending emails, authenticating data, etc.

A design could be this:

More simple mockups are these:

The user starts the Application and is presented with an option to select a single key to be signed by the other person. We assume the user to have more than one key, but not more than a dozen. We might want to save the information about the selected key for later. We could also, in the future, think about handling multiple keys.

Once a key is selected the problem to solve is how to get that key to the other (signing) party. Ideally, we would open an authenticated channel much the same way Bluetooth does it. But we can also authenticate the (potentially large) data on an untrusted channel using, e.g. a (very short) message authentication code (MAC). That MAC can be the fingerprint of the OpenPGP key. For now, the simplest thing seems to be to encode the fingerprint as a barcode and transfer that securely via the signee's (laptop) screen. In could also be possible to transfer the whole key in a barcode (although I think I remembered a typical OpenPGP key to be too large to fit a QR code. It could be possible that other bar codes can fit a key. Research is needed here.)

The application would then register itself on the network using, e.g. dnssd, so that the other party can find it and transfer data (insecurely), i.e. via HTTP (or HKP).

The signing party needs to obtain the authenticated key. As we've settled on transferring data insecurely, we need to securely obain the MAC. For now, we plan to do it with a barcode. We thus need to present the user with a way of scanning the barcode. (Fortunately, Monkeysign seems to have already implemented that). Alternatively, also as a last resort, the fingerprint of the key to be signed can be entered manually.

Once the MAC has been obtained, the data from the clients on the network can be received. Only the data that validates correctly under the MAC will be processed. This will not scale with many people or keys on the network, but the scenario is deliberately simple for now. As the data has been authenticated, the application does its magic like signing the key, preparing an encrypted email to the signee, and sending it off. The user should be informed about the steps taken and maybe nagged to confirm that the key is indeed signed and an email is sent.

More things to think about: Shall we also offer to "undo" a signature, i.e. revoke a signature? That would offer a different can of worms such as where to distribute the new revokation signature to. How to decide which key to sign the other key with? How to bootstrap a user who does not have a key?

Of course, technical details need to be thought out:

• How to integrate monkeysign best
• How to actually send an encrypted email programmatically
• What other parts of the desktop are worth integrating with
• What can we do to actually open an authenticated channel?