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

[Stephen J. Turnbull]

Daniel Kahn Gillmor writes:

 > I think Abhilash's question above is a really important question,

It is.

 > and one that really should be addressed by this GSoC project.

Vetoed (I'm the mentor).  Abhilash is welcome to work on key
management if he wants to, but he will not be evaluated on it (subject
to satisying the need discussed below for a simple, generic mechanism
to allow the list owner to conveniently authorize keys without
uploading them himself), and he will be warned if it appears that
mission creep is endangering the mission.

He is also welcome to use any free time he finds to work on encrypted
lists, and there's been mention of a conceptually similar project on
DMARC implementation (a message-signing technology for use by MTA
owners rather than list owners and members) that he may want to work on.
Which, if any, to do is up to Abhilash.  You're welcome to continue to
lobby him to work on key management though (in public, please :-).

But let's drop the discussion of a relation to GSoC, please.  Abhilash
has his contract, and key management policy is not in it.

 > I'm not claiming that the implementation needs to be perfect, but i
 > do think mailman should support something more sophisticated than
 > "oh, anyone can just upload a new key via the webinterface".

Nobody is saying otherwise.  I'm just saying that key management in
general is not Abhilash's problem for GSoC.  There does need to be a
way for list owners to take complete control of key management, and
there does need to be convenience in management.  I think that the
"key signed by list-owner's list-key-management-key" is an important
step for convenience.  I suspect that the hook needed to implement it
would be able to support various policies (probably through the 'chain
of rules' mechanism implemented in Mailman 3 core -- might require
some refactoring of core I guess).

 > I like this latter proposal, and it should be pretty
 > straightforward to implement.  This means, of course, that the
 > list-owner's key needs to be known to the mailman instance.  could
 > there be more than one list-owner's key?

Yes.  As implied above, I envision there being a specific key used to
sign for permission to do X FVO X such as subscribe, post, get member
list, sign other people's keys (Web of Trust!), etc, so there could be
several keys in that sense.  For paranoid folks who regularly expire
their keys, I would expect that keys might overlap in time, so there
probably should be a list of keys for each function.  In some cases
one key will fit all, of course: "I only sign for people I trust to do
everything a signature gives authorization to do".

 >  A) if refreshing keys from the keyserver network is something we want
 >     mailman to do, when should it happen?  how often?

Good questions, both the implicit one (do we want?) and the explict
ones.  Beyond my technical knowledge at the moment, though.

 >  B) if mailman can't find a valid key+userid for a known subscriber,
 >     when should it query the public keyservers to try to find one?

Immediately, subject to the caveat that this would possibly be a
separate queue.

Oh, I suppose you mean "should Mailman automatically add a key
that the user may not really have intended to use?"  That's an
extremely complex question.  If "signed by list owner" is the only
criterion and it's necessary and sufficient, I'd go with "always".
Otherwise you have a complex policy, and I'd have to see the policy to
know when querying is appropriate.

 >  C) how should mailman accept uploads of key material that *don't* go
 >     through the keyservers?

Please expand.  A signed key is a signed key, or isn't it?

 >  D) if mailman notices that a subscriber's key has expired or been
 >     revoked or somehow become invalid in some other way, is it expected
 >     to notify that subscriber of the change in status?  if so, how? (i
 >     recommend that the answer is "no notification", at least in this
 >     initial implementation.

I would expect that "noticing" would happen during the process of
authenticating a request.  If key status *changes* (a key that was
never valid for the list should cause silent denial of the request to
reduce backscatter), then the user should be notified that key status
has changed *and* how that was determined.  Anything else is going to
leave the list owner in the dock.  Also, the key owner may wish to
prosecute somebody for misuse of her key, and should be informed of
the misuse.

Steve