Daniel Kahn Gillmor writes: > Maybe we're not talking about the same thing. OpenPGP certification > should be identity certification, and nothing else. trying to extend > OpenPGP certification to mean something other than identity > certification sounds like a bad idea to me -- it breaks all kinds of > other assumptions within the OpenPGP world. > > I was thinking that the baseline is: > > 0) each e-mail list has a set of "identity certifiers"
Yes. > 1) each "identity certifier" is itself an OpenPGP primary key > fingerprint (or, the primary key itself). Yes. Probably the primary key. > 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe, > unsubscribe, receive, and send mails as usual (though messages not > signed with valid keys will not be re-sent to the list). Not necessarily. It may be necessary to sign admin messages as well (subscribe, unsubscribe, set vacation).... Your phrasing presumes that the only role of Users (the internal representation of an identity) is to act as a subscriber who reads and posts. The way I think of it is that Users may have several roles (read, post, moderate, admin) for each list. Each of these roles may be certified by a different "agent" of the owner, where agents are represented by different keys. > 3) if a signed message comes in, the server checks to make sure that > the message is signed properly with a key that is certified (by one of > the list's "identity certifiers") to belong to the person in the > message's "From:" header, *and* that person is a known subscriber to the > list. "Known subscriber" doesn't really make sense in the Mailman 3 world. There are Users, they can be "members" of a list (ie, known to the list) and they can have roles (reader, poster, etc). It's not clear to me that requiring posters to have the reader role in this world is the right way to determine membership. > so when you say "certified key" above, i think you're talking about what > is known as a "valid" key -- that is, the relevant user ID is bound to > its primary key by a certification made by one of my trusted identity > certifiers. That seems to be nonsense, though. Key-to-UID binding is done by the user database; it's only meaningful inside of Mailman. A signature on a key is not a way of making an authenticated link to a UID in Mailman, AFAICS. It's only a of certifying that the signer knows the keyholder and that this is that keyholder's key, and that the signer trusts the keyholder not to allow others to use her key. That doesn't mean (in the absence of actually binding a UID to the key *in* the certification) that this keyholder corresponds to any given UID. So this interpretation is useful only if a new UID is being assigned to that key in this transaction. It doesn't work if we are binding a new key to an existing UID. I also don't see why, in a web-of-trust model, you would want to use that definition of "valid". (If the key is determined to be none of corrupt, expired, or revoked, I would call that "valid".) A key not signed by a trusted certification key would be (completely) untrusted, but you can imagine various degrees of trust. For example, in a member recommendation model, you might allow any member's key to certify the reader role but not the poster (or vice-versa for a list handling privacy issues!) Having validity depend on trust makes the concept of validity quite ambiguous. > > 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. > > certification expiry means "i am willing to claim that this key belongs > to this person for N months; if it's later than N months, and you don't > see a newer certification from me, please don't rely on my claim any > more". I think it would be a mistake to interpret that any other > way, I don't interpret it any other way. I'm assuming that once the key is registered, Mailman and the list owner take responsibility for trusting keys, and they no longer rely on the certification at all. If the list owner wants to use the "certification" in authenticating the User, that would be OK. But then the temptation to use an infinite expiry would be strong (unless a mechanism is provided to make re-signing convenient -- but not *too* convenient: sorry, no "re-sign all" button will be provided!). With infinite expiry certification is meaningless in the long run (in the long run we're all dead, and a signed message from someone known to be dead should be a clue...). > since that is the default interpretation of other pre-existing > OpenPGP clients that will be seeing these same certifications. Why are they delegating so much power to the certifications? That seems very strange to me. I certainly wouldn't stop trusting a key that had been used to sign messages to my list daily just because a third party certification from 6 months ago expired! _______________________________________________ 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