[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration

Abhilash Raj raj.abhilash1 at gmail.com
Sat Jun 15 07:42:19 CEST 2013


This is a list of topics that probably needs to be discussed in detail
again. I tried to mention in breif about the discussions in past
personally with a someone or on mm-dev list. Please ignore the topics
which you feel has already reached a inference. It is a long mail though.

* How to ensure the keys belong the email it says it does?

  One method proposed for this was to send a confirmation email to the email
  address, but what if the email is intercepted in between and the attacker
  confirms the sign up of the person he is trying to impersonate? Or
  this is a problem that can be solved with SSL and is not of our concern?

* Inline pgp should be supported or not?

  Although its not included in one the best practices but some people still use
  it for the purpose of signing only a part of the email.

* How to handle partial multipart/signed messages?

  In previous discussion it was pointed out that we should strip off the
  parts till we actually arrive at a point where the signature verifies
  all the text and then send that part to the subscribers. Other options
  were to discard these kind of email or let the owner decide what he
  wants.

* Should mailman keep the signature of sender before signing or strip if off?

  In previous discussions it was mentioned that user's signature can be kept as
  it is and the list re-signs the message before sending the subscribers as
  subscribers may want to confirm if the email was originally sent by the user in
  the From address. But there might be a case of anonymous list where identity
  of the sender should not be revealed and is only verified that any one the
  members sent the email. So can we introduce this as an option?

  About introducing options I agree to a point mentioned in the
  mailman-pgp-smime patch for mailman where it says that although there are lots
  of ways we can allow the list owner to configure a list, we should only
  provide minimal options to avoid unexpected scenarios where the list's
  security is compromised due to lots of options.

* Should we make the sending of signed copies of email default?
  
  We can introduce an option to send signed email by default for those who want
  may verify the email, but is there a point in sending singed email when the
  mails received are not signed? Or this could be a good point?

* Email interface to manage keys?

  Mailman has a set of email commands to process the requests for subscription,
  change password and many other things over email without a web interface, so
  to allow managing keys over email we could allow receiving signed emails with
  new keys and command to add them, the confirmation mail for the new key will
  then be sent to the same address but would expect a signed reply from the new
  key.

* How are we actually using the web-of-trust model of OpenPGP? 

  Should there be any restrictions on the key to implement the
  web-of-trust model which advocates for the authenticity of the key
  provided by the user? Something like it must be signed by 2 or 3
  people or anything like that?


About the implementation I decided to take up with the processing of
email part first and then setting up the PKI for the users. The flow
would be something like this:

* the message is queued in incoming queue
* the incoming runner wakes up, finds the message and calls a few
  functions to verify the signature of the message(assuming the function
  already has public key of the user from somewhere)
* If the message signature is found to be valid the message is then
  passed on to onther runners as usual (without stripping of the
  signature as per my assumption till now, need discussion on this) else
  it is dropped or bounced depending on the state of verification( like
  if the signature is older we can inform the sender as the delay may
  have been due to smtp deliver and simply drop the message if the
  signature is verified to be wrong).
* Now a valid signature would be a signature signed within 4
  days(default and configurable by list owner) from when mailman
  receives the email.(Is there someway to also check if the signature
  was previously sent on the list? so that we can block that also?)
* After that the message passes on to various other queue and runners as
  usual and when finally it arrives at outgoing runner it again calls a
  few functions to sign the message and send it to MTA.

I think the function to prase message, check signature, resign message
could be there in utilities as a gpg.py module. Which is where I think I
should first start from. I was looking for a python wrapper for gnupg
and found two options: [python-gnupg][2] and
[gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime
patch for mailman 2.1.5. I don't have much idea about waht should be
used, will post on mailman-developers.

About the outgoing messages i was thinking if we can create a signing
queue and sign runner which simply signs each message with list's
private-key and then the message moves on to outgoing queue where it can
be delivered without any furthur changes. Any ideas about this?

--
Abhilash Raj


More information about the Mailman-Developers mailing list