You have a key K and keys K1 to Kn (this is your public keyring). Furthermore, the keys Ki1 to Kik (1 <= i1 <= .. <= ik <= n) are certified/signed by K. After defining K as a "key-selector", encrypting to K triggers encryption to {K, Ki1, ..., Kik}.

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 takes the keys of the mailinglist members and signs each of those keys with the list key. The list admin cares about privacy in respect to mailinglist membership and thus adds local signatures to the members' keys instead of standard (exportable) signatures. Now the list admin exports the members' keys (a special hack is neccesary for exporting local signatures) and sends them to each members.

Some configuration needs to be done on the member side: the list key needs to be registered as a "key selector".

Each members imports the bunch of keys. When a members wants to encrypt to K, the message is transparently encrypted to every key which is certified/signed by the list key.

• 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) some keys when mailinglist membership has changed.
• It's not a standard feature of GnuPG.

There is a wrapper for GnuPG which implements the key-selector feature. It's named GPG-SecML and can be found at Savannah.