[Mailman-Developers] Public-key signing+encryption plugin API foreseeable needs

[J.B. Nicholson]

Barry Warsaw wrote:
> Does that make it worth it to add as a supported feature in the core?  It
> depends.  What I would be very interested in -at least as a first step- are
> ways to enable experimentation into such features by the addition of hooks and
> APIs that allow third-party plugins that could support this feature.
> Presumably such plugins would have utility for other use cases too.

I was thinking this same thing; if Mailman had such hooks and an API 
allowing people to write plugins, everything discussed in this thread so 
far could be done with a plugin.

The overall goal for this plugin's API needs is to allow a Mailman admin or 
list owner to install this plugin and see the normal Mailman UI change 
slightly in relevant places to accommodate the needs of public keys.

Such a plugin for this task would need to:

- have read access to each inbound message sent to a list where this plugin 
is supposed to be active. This is used to check a signature and possibly 
decrypt a message intended for list consumption when people send commands 
to the list encrypted with the list's public key.

- somehow signal acceptance/rejection (to the next stage in Mailman's 
normal processing queue) of a message as coming from a subscriber (for 
lists where only subscribers may post) or a suitable other user (for lists 
where non-subscribers may also post).

- get read/write access to each outbound message from a list before it is 
mailed to subscribers. This is where the list-signing + encryption would be 
done.

- make a list command (even one that overrides the normal Mailman list 
commands) so one could do things with public keys relevant to this plugin 
-- subscribe to a list and supply either a pointer to or a copy of a public 
key at the same time in the same subscribe command, for example. I imagine 
there would be other commands that need similar public key additions to syntax.

- be able to add fields, table columns, and form elements to an extensible 
web UI so key-related functions and displays can be integrated into extant 
displays -- subscribing on the web should include a prompt where one 
uploads one's public key or provides a URL where Mailman can fetch said 
public key. Getting a list of subscribers (if that's allowed per list 
policy) should include perhaps the key signature of each subscriber (if 
that subscriber is okay with publishing that info), the subscriber info for 
each list should include a setting where each user can decide if they want 
the list to publish the key signature (I think this is akin to current 
Mailman asking about hiding the user's identity in the subscriber's list), etc.

- a way to place the list's public key in a file everyone could read at a 
predictable static URL. MUAs would use this URL to automatically fetch the 
list's public key.

- a way to add to the documentation describing the plugin's added 
functionality; best would be to not have to replace extant documentation 
pages, but add pointers in current documentation pointing to new pages 
(which are installed in a place along side extant docs).


The plugin might also need an acceptable place on the server to store state 
data: a GPG keyring holding a copy of each subscriber & moderator's public 
key, the list's public and private keys, and some temporary space where the 
list can do work signing+encrypting messages (or perhaps GPG has a better 
way to handle this and the plugin should use whatever GPG provides).

I'm not familiar with Mailman's current hooks/API to know if any of this 
already exists, or is in-line with how Mailman generally does things.

Functionally, the list needs to inform all subscribers of the new list 
public key each time it changes. Maybe that is done with a header in a post 
with the list's public key's signature (saying the key with this signature 
was used to sign+encrypt this message) and it would be up to the MUA to get 
(and cache) the appropriate public key to verify this post?

There are also some policy issues I raised in another post on this thread 
regarding GPG's support for: obsolete hash/encryption algorithms, how this 
project wants to handle list archives (particularly re-signing+encrypting 
list archives). I think those issues should be considered. They seem to me 
to be important factors in how everyone interested in the list would use 
the list.

Finally, I'm not sure what the goals for the project were in the first 
place and the goals I posted are really only things I think are possible to 
implement.

Here's another of my guesses aimed at succinctly describing what this 
project will do: replace the subscription and posting filtering mechanism 
(currently based on email address string comparisons) with public key 
cryptography; if one sends in a post from any email address signed (or 
signed+encrypted, as per list policy?) with the right public key, that post 
is deemed to come from a subscriber. Other posts are handled in accordance 
with list policy.

If the project leader could speak to the project's goals, it might help us 
all understand what's in and out of scope for the project.

Also, thanks for letting someone completely unconnected with this project 
chime in out of nowhere.