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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9