Abhilash Raj writes:
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?
This is not in scope for your project. Key upload is for bootstrapping strong authentication, therefore you should assume there is no strong authentication to authenticate the key upload. Man-in- the-middle attacks on the key upload mechanism are *way* above your pay grade.
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.
It depends on how it gets used. If there are MUAs that do this without consulting the user, then we should support it eventually. If it requires a user's guidance to get that result, then we can just tell them "Don't do that."
You should give a reference for "not best practice."
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.
I think we should handle it. Among other things, if you want the originator headers signed, I would think the easiest way to achieve that would be to send a signed message/rfc822 part.
- Should mailman keep the signature of sender before signing or strip if off?
Needs to be an option. By default, the sender's signature should be kept so that recipients who know the sender well enough to have his key can verify it. This may also help with catching key fraud. But as you say it could be used to identify a poster, and that might be bad in some contexts.
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?
I don't understand what you're suggesting. I think the list should be capable of signing mail itself, even if incoming mail is not signed, yes. For example, posting may only be allowed by the list owner from localhost, and signing is a convenience.
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.
Seems reasonable as an extension if you have time.
- How are we actually using the web-of-trust model of OpenPGP?
We aren't. Simplistic rules like "two signatures" are not going to be good enough for anybody who cares. Writing a framework so that admins can configure the signature policy is also above your pay grade. You should consider providing hooks for such validation, and maybe a proof of concept implementation to hook into it. Something like "a key is considered valid if it is signed by the list-owner".
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)
I think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking.
- 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?)
Here and in the previous point I don't think you should be adding policy options yet. I don't see why we need to consider dates other than the issue of expired keys. Similarly for revoked keys, but of course we can't tell that very easily.
- 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.
Similarly to the above, I don't think this should be done in the outgoing runner, but rather in the Handler pipeline.
I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module.
Maybe. Again you should check current style. I Think what you propose is OK, as Rules and Handlers can live in the same file since they are distinguished by their signatures. But I forget exactly how Barry organizes this stuff.
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?
Queues imply storage. I don't know if we are thinking about any threat models in which the attacker could change content after validation of the poster's signature and before resigning as the list, but you want to be careful about proliferating queues.
Steve