Mark Sapiro writes:
On 11/18/2016 07:26 AM, Dominik wrote:
I'd like to see PGP support for MM3 but I thought it might be a little to early to file an issue.
It's too late. :-) The issue has already been raised, years ago. So far the complexity has deterred people from actually doing anything about it. (I hasten to add it's not *that* hard, it's just that so far everybody except our GSoC students who has proposed adding crypto to lists has balked at the idea that you actually have to think about your threat model, and gone away at that point.)
Which one of these points a worth an implementation?
All of them. Individually and in various combinations. And that's the problem from our point of view. If somebody would tell us *what* they want, do a lot of the work on identifying threats, and maybe do a coding, we could provide the *how* and help do implementations one at a time. But we don't have itches to scratch ourselves, and plenty to do besides building a better mousetrap when the customer has a cockroach problem.
Steve may be able to provide more info.
Abhilash Raj actually worked on the "signed list" GSOC project. I don't know if he's still interested in that particular project but I believe he maintains his interest in security. I hope he'll get involved in the conversation. (It may be a couple of weeks, though, I know he's facing deadlines at school.)
As Barry mentions in a parallel response, at least at the present time, there is no good theory of security that would allow us to provide a single, simple "crypto-enabled list" configuration, or set of options. Rather, due to the nature of email, there are a very large number of use cases and corresponding threat models, and each requires a unique configuration.
Picking one or more and getting started on implementation, and especially user documentation, would be welcome. Aside from Abhilash's work, we also have this summer's work on Authenticated Received Chain (ARC) by Aditya Divekar that uses crypto technology, but it's a very special use case, and has some really smart IETF people behind it so it's well-defined.
It's the definition of use cases and threat models that users would like us to address that is the main task now. Once have that, we can start building up the components for handling keys and various signing and encryption configurations. Steve