[Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

[Stephen J. Turnbull]

Richard Damon writes:

 > One big thing that I haven't seen in the discussion of this problem is 
 > exactly WHAT issue/problem this feature is intended to solve, There are 
 > several different problems that encryption can help with, each needing 
 > different sort of support from the software.

Yup, and I've been telling the prospective interns that throughout.

But Rich Kulewiec is right that many or most of them can be eliminated
right off.  For example, I don't see any point in actual end-to-end
encryption, as that would require everybody to know everybody's keys.
OK, so we could create a PKI for each list, but that's effort over and
above the encryption module, probably not appropriate for this GSoC.
(It's been mentioned that algorithms are not forever, but similarly I
think that's out of scope.)  AFAICS, this means that root on the
Mailman host is trusted, and needs to know the session key for each
message.  Perhaps you can avoid having to trust list owners, but when
does that scenario actually make sense?

Note that GSoC is Google Summer of CODE - the reason for being cagey
about what I'm thinking about as specs and use cases is not that the
intern will be responsible for design.  It's that the intern needs to
understand that design and the use cases it serves in order to
determine whether the implementation is correct, write tests, and so
on, and I prefer to mentor Socratically.  That doesn't mean anybody
else needs to be coy!  Feel free to put your ideas about use cases out
there.

Also references to existing knowledge would be appreciated, such as
"zero knowledge" schemes that might allow untrusted root on Mailman
host, and the various implementations like SELS that have been
mentioned.

Steve