On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > * How to ensure the keys belong the email it says it does? > > This is not in scope for your project. Key upload is for > bootstrapping strong authentication, therefore you should assume there > is no strong authentication to authenticate the key upload. Man-in- > the-middle attacks on the key upload mechanism are *way* above your > pay grade.
I think Abhilash's question above is a really important question, and one that really should be addressed by this GSoC project. 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". > > * How are we actually using the web-of-trust model of OpenPGP? > > We aren't. Simplistic rules like "two signatures" are not going to be > good enough for anybody who cares. Writing a framework so that admins > can configure the signature policy is also above your pay grade. You > should consider providing hooks for such validation, and maybe a proof > of concept implementation to hook into it. Something like "a key is > considered valid if it is signed by the list-owner". 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? If someone wants to propose a more sophisticated key verification step later, that could be an extension. The above proposal makes the following things possible: 0) mailman can fetch keys directly from the OpenPGP keyserver network if they haven't been uploaded directly, and still retain a reliable cryptographic chain (since any fetched keys that are not signed by the list-owner should be ignored). 1) mailman can refresh keys automatically from the OpenPGP keyserver network, or accept arbitrary uploades of updated keys, also without worrying about non-cryptorgraphic compromise. This means that people can update their key's expiration dates, and they can publish key revocation to the public keyserver network without needing to worry about fiddling with their subscription on every mailing list directly. These are great! It does raise a few logistical questions: A) if refreshing keys from the keyserver network is something we want mailman to do, when should it happen? how often? 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? C) how should mailman accept uploads of key material that *don't* go through the keyservers? 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. Thanks for weighing these options! --dkg
pgpCLn0gzOaTy.pgp
Description: PGP signature
_______________________________________________ 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