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

[Stephen J. Turnbull]

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