If you have a key K and keys K1 to Kn, you can install "key references" to keys K1 to Kn in K. When encrypting to K, GnuPG sees the key references and also encrypts to the referenced keys.

Say your mailinglist is named secret@example.com. The list admin generates a "list key", i.e. a key with a UID of secret@example.com. Now the list admin installs references to the list members keys into the list key and sends the updated key to the list members. The members import the updated list key and when they send encrypted mail to secret@example.com, GnuPG actually encrypts to all of the members.

• No encryption/decryption takes place on a central mailserver, which means: no trusted mailserver with admin access is required.
• No special support in the MUA is required.

• It might be slow, since each member encrypts to all members of the mailinglist; but this isn't too much of a problem, since secured mailinglists would be rather small anyway.
• Members need to update (reimport) the list key whenever the list admin sends an updated list key to the list.
• It's not (yet?) a standard feature of GnuPG.

Key references are implemented as special user IDs holding the key fingerprint of the to be referenced key (OpenPGP says explicitely that user IDs do not need to contain e-Mail addresses). Thus, key references are managed through the adduid/deluid commands.

Install a patched version of GnuPG 1.4.7. Have your key, which shall become a multikey. Edit the key with:

gpg --allow-freeform-uid --edit-key KEYNAME

Then use the "adduid" command to add a new user ID. The "real name" for the ID shall be:

KEYREF 2E181822146811F74BDF2A7512762417CF0508EC

where 2E181822146811F74BDF2A7512762417CF0508EC is the long key fingerprint of the key which is to be referenced (the user ID shall have no e-mail address or comment associated). You can lookup key fingerprints with: key ID for a key with:

gpg --with-fingerprints --list-key KEYNAME

If you like, make sure that the "real" user ID (not the KEYREF user ID) will be the "primary user ID" with:

uid n

Where n is the number of the user ID you want to become the primary one. Then:

primary

And finally:

save

Now you should have a key with a key reference on it. The KEYREF uid should be displayed fine when listing the key.

Given that this multikey is trusted, encryption to the multikey should yield in additional encryption to the referenced key.

Note that this patch is highly experimental. There is absolutely no warranty.

Get it here: