[openpgp] Mailing lists

["Neal H. Walfield" <[e-mail]>]

Hi,

Encrypted mailing lists are currently difficult to do securely and
easily.  Either they trade security for usability by reencrypting mail
or they trade usability for security by requiring each poster to keep
a local list of subscribers up to date.

I think many cases can be easily accommodated at the OpenPGP level.
My proposal is relatively informal.  This is because: I haven't
actually implemented it yet; I would like some feedback on the idea
before pursuing it further; and, I don't have any experience writing
RFCs.  If the community agrees that the approach is reasonable, I'll
be happy to draft a more formal specification / patch for 4880bis.

The basic idea is to publish the list of subscribes as an OpenPGP
message.  Concretely:

  To create a mailing list, the mailing list administrator generates a
  new key pair in the usual way.

  Associated with the key pair is a list of encryption keys
  (Public-Key Packet, tag 6, or Public-Subkey Packet, tag 14).  Each
  key may optionally be preceded by a user id (User ID packet, tag
  13).  This list is stored in a signature subpacket with a new
  subpacket type.

    The list may be encrypted to hide the subscriber list.  In this
    case, the list will be encrypted to the set of authorized posters
    (which may or may not be the same as the set of subscribers).  The
    session key is encrypted for each poster and is saved in a
    public-key encrypted session key packet as usual.

    Since it is useful to hide the list of posters, as an extension to
    the public-key encrypted session key packet specification, if the
    first 6 octets of the key id are 0 and the last two are not, then
    the last two octets specify the last two octets of the key's id.
    I call these are "practically hidden key ids".  They are
    practically hidden, because 16-bits does not provide enough
    information to identify a key (it's trivial to create a collision
    unlike with a 64-bit id) and thus plausible deniability is
    ensured.  The 16-bits are useful, because there are potentially
    thousands of posters to a mailing list and if the public-key
    encrypted session key packets all have hidden key ids, it could
    take a long time to find the appropriate packet.  The 16-bits are
    a simple filter that reduces decryption time by a factor of 2^16.

    Keyservers / export commands should only include the most recent
    valid version of this packet.

  The key may contain two optional uids.  The first uid contains an
  email address that forwards the email to all of the mailing list's
  subscribers.  This user id has the following comment: "mailing
  list".  If there is no valid user id with the comment "mailing list"
  then the MUA should send the email to all of the UIDs listed in the
  encryption key list.  The second uid contains the email address of
  the list's owner.  It should have the following comment: "mailing
  list: owner".
  
  When encrypting, the implementation should make sure that the key is
  fresh.  It could do this by automatically downloading the key from a
  key server or, if the key hasn't been updated in the last 24 hours,
  by issuing a warning.

Thanks!

:) Neal