GPG keys for mailinglists

Question

There are two mailing-lists (e.g. [email protected] and [email protected]) for which I'd like to generate GPG keys and send the respective private keys to the members of the lists, so mails to the lists can be sent encrypted without having to know the pubkeys of the members of those lists. - So far.

Further there is an alias address, of which mails are forwarded to both mailing-lists (e.g. mails to [email protected] are forwarded to [email protected] and [email protected]).

                       | 
                       V
Alias:             [email protected]
                       /\
                      /  \
                     /    \
                    /      \
                   /        \
                  /          \
                 /            \
                V              V
Lists:    [email protected]    [email protected]

How can I include this second address/identity so that both lists can decrypt mails that are sent to [email protected], without having to generate a 3rd keypair for [email protected]?

The problem is that when I add [email protected] as second identity to [email protected] and [email protected], the senders mail-client will encrypt it to one key only ([email protected] or [email protected] and not both).

I also tried to generate a second subkey in [email protected] which I exported and tried to import to [email protected], which failed.

Is this doable at all or does this have to be solved via an mta/mda?

Answer 1

Solution 1: shared secret

I fear there is no easy, clean solution. If you don't want the others to have to encrypt to multiple keys, you'll need a shared secret key between the two "real" lists. As this can't be the only one, you'll have to create a third one holding the public key for this.

You can actually achieve this using rather complex split-and-join operations, similarly as described in "Migrating GPG master keys as subkeys to new master key". This will require deep knowledge of RFC 4880 (OpenPGP).

In the end, you should have a structure similar to:

• Primary key 1
  • UID [email protected]
  • shared subkey
  • subkey 1
• Primary key 2
  • UID [email protected]
  • shared subkey
  • subkey 2
• Primary key both
  • UID [email protected]
  • shared subkey

Solution 2: reencrypting

In my opinion, implementing an MTA that performs reencryption for the individual recipients would be a better option. And not only reencrypting for both lists, but each recipient individually.

Consider what happens if somebody leaves one of the mailing lists. You're not able to revoke his access without sharing new (sub)keys to all of the members!

There seems to exist an inactive modification for mailman for this purpose, or you loop the list through an encrypting MTA like geam.