Daniel Kahn Gillmor writes: > ok, of course you have priority here, but i don't think we're actually > disagreeing :)
Good! > The "simple, generic mechanism" you describe *is* key > manangement as far as i'm concerned, and i think it's an excellent > step. OK. I remember the context as being one of actually implementing (automated) policy decisions. That's where I really don't want him to go until the more limited GSoC project is done. > OpenPGP certifications should attest to people's identities; those > identities should have permissions in mailman the same way that > non-cryptographically-verifiable identities have permissions in > mailman. > > The semantics are simple and graspable if we say "for list X, rely on > OpenPGP certifications from the following keys to prove cryptographic > identity". So you're suggesting that the *only* policies that should be automatically implementable via certified key are (0) let this guy upload this key (and implicitly create a User if needed), but he can't do *anything* else (not even subscribe) until the list owner explicitly adds authorizations, (0.5) this guy gets the intersection of sets of privileges I ever want to grant to anybody, and (1) this guy is co-owner of this list ? > i can see how this would be useful, but it means that there is more > fiddly tracking of the validity state of each (key,userid) pairing > that needs to be done to make this possible. I agree it's fiddly, I agree it's not in scope for Abhilash's GSoC project, but for Mark's[1] sake I think we need to notify users whose status changes from valid to invalid of the reason for the change. > I suspect that the most common change from valid to not-valid will > be an expired key or an expired certification (e.g. if the list > owner's certification of the key expires). for the latter case, i > can imagine that the certifier (the list admin) might want to be > notified as well. I would interpret a certification expiry differently: as the period of time for which permission to register the key is valid. If we want an expiry for User authentication, probably a generic tool for managing that in Mailman itself would be sufficient for this purpose and useful elsewhere. Footnotes: [1] He's the guy who does the most work on fielding problem reports from users. _______________________________________________ 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