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