Joost van Baal-Ilić writes: > Indeed, that could work. Another way to deal with it could be: "a > key is considered valid if it is imported in the trusted keyring of > the current list". And declare deciding wether to import out of > the scope of the project.
I think that we necessarily have to trust the list's keyring, that's what it's there for. The question is how do keys get into the trusted list. What I had in mind was that "signed-by-list-owner" would be a reason to import automatically. The model I have in mind is that signing Mr. A's key means the list owner is willing to vouch for authenticity of that key to others, meaning he know Mr. A (including where to find him if he cheats). This is probably good enough for lists where the 3-way handshake (subscribe, request confirmation, confirm) is good enough authentication of the mail address itself. On the other hand, it's still not a strong authentication in the sense Abhilash wants. Mr. A might have tricked the list owner into signing a throw-away key which will be used to spoof Mr. B's email address. A similar trick would defeat Barry's scheme of sending the one-time key in encrypted form, if the bad guy both submits the PGP key and can intercept Mr. A's mail. Both of these schemes have some merit in that there's a very short window of opportunity for the bad guy. Once an authentic key has been linked to an address, authentication is very strong. _______________________________________________ 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