A list of discussion topics: GSoC OpenPGP Integration

This is a list of topics that probably needs to be discussed in detail again. I tried to mention in breif about the discussions in past personally with a someone or on mm-dev list. Please ignore the topics which you feel has already reached a inference. It is a long mail though.
How to ensure the keys belong the email it says it does?
One method proposed for this was to send a confirmation email to the email address, but what if the email is intercepted in between and the attacker confirms the sign up of the person he is trying to impersonate? Or this is a problem that can be solved with SSL and is not of our concern?
Inline pgp should be supported or not?
Although its not included in one the best practices but some people still use it for the purpose of signing only a part of the email.
How to handle partial multipart/signed messages?
In previous discussion it was pointed out that we should strip off the parts till we actually arrive at a point where the signature verifies all the text and then send that part to the subscribers. Other options were to discard these kind of email or let the owner decide what he wants.
Should mailman keep the signature of sender before signing or strip if off?
In previous discussions it was mentioned that user's signature can be kept as it is and the list re-signs the message before sending the subscribers as subscribers may want to confirm if the email was originally sent by the user in the From address. But there might be a case of anonymous list where identity of the sender should not be revealed and is only verified that any one the members sent the email. So can we introduce this as an option?
About introducing options I agree to a point mentioned in the mailman-pgp-smime patch for mailman where it says that although there are lots of ways we can allow the list owner to configure a list, we should only provide minimal options to avoid unexpected scenarios where the list's security is compromised due to lots of options.
Should we make the sending of signed copies of email default?
We can introduce an option to send signed email by default for those who want may verify the email, but is there a point in sending singed email when the mails received are not signed? Or this could be a good point?
Email interface to manage keys?
Mailman has a set of email commands to process the requests for subscription, change password and many other things over email without a web interface, so to allow managing keys over email we could allow receiving signed emails with new keys and command to add them, the confirmation mail for the new key will then be sent to the same address but would expect a signed reply from the new key.
How are we actually using the web-of-trust model of OpenPGP?
Should there be any restrictions on the key to implement the web-of-trust model which advocates for the authenticity of the key provided by the user? Something like it must be signed by 2 or 3 people or anything like that?
About the implementation I decided to take up with the processing of email part first and then setting up the PKI for the users. The flow would be something like this:
- the message is queued in incoming queue
- the incoming runner wakes up, finds the message and calls a few functions to verify the signature of the message(assuming the function already has public key of the user from somewhere)
- If the message signature is found to be valid the message is then passed on to onther runners as usual (without stripping of the signature as per my assumption till now, need discussion on this) else it is dropped or bounced depending on the state of verification( like if the signature is older we can inform the sender as the delay may have been due to smtp deliver and simply drop the message if the signature is verified to be wrong).
- Now a valid signature would be a signature signed within 4 days(default and configurable by list owner) from when mailman receives the email.(Is there someway to also check if the signature was previously sent on the list? so that we can block that also?)
- After that the message passes on to various other queue and runners as usual and when finally it arrives at outgoing runner it again calls a few functions to sign the message and send it to MTA.
I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module. Which is where I think I should first start from. I was looking for a python wrapper for gnupg and found two options: [python-gnupg][2] and [gnupg-interface][3]. GnuPG-Interface was what was used in pgp-smime patch for mailman 2.1.5. I don't have much idea about waht should be used, will post on mailman-developers.
About the outgoing messages i was thinking if we can create a signing queue and sign runner which simply signs each message with list's private-key and then the message moves on to outgoing queue where it can be delivered without any furthur changes. Any ideas about this?
-- Abhilash Raj

Abhilash Raj writes:
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.
It depends on how it gets used. If there are MUAs that do this without consulting the user, then we should support it eventually. If it requires a user's guidance to get that result, then we can just tell them "Don't do that."
You should give a reference for "not best practice."
I think we should handle it. Among other things, if you want the originator headers signed, I would think the easiest way to achieve that would be to send a signed message/rfc822 part.
Needs to be an option. By default, the sender's signature should be kept so that recipients who know the sender well enough to have his key can verify it. This may also help with catching key fraud. But as you say it could be used to identify a poster, and that might be bad in some contexts.
I don't understand what you're suggesting. I think the list should be capable of signing mail itself, even if incoming mail is not signed, yes. For example, posting may only be allowed by the list owner from localhost, and signing is a convenience.
Seems reasonable as an extension if you have time.
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 think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking.
Here and in the previous point I don't think you should be adding policy options yet. I don't see why we need to consider dates other than the issue of expired keys. Similarly for revoked keys, but of course we can't tell that very easily.
Similarly to the above, I don't think this should be done in the outgoing runner, but rather in the Handler pipeline.
I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module.
Maybe. Again you should check current style. I Think what you propose is OK, as Rules and Handlers can live in the same file since they are distinguished by their signatures. But I forget exactly how Barry organizes this stuff.
Queues imply storage. I don't know if we are thinking about any threat models in which the attacker could change content after validation of the poster's signature and before resigning as the list, but you want to be careful about proliferating queues.
Steve

On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote:
Right. Remember that all the incoming runner does[*] is take a message that's already been parsed, and send it through the "posting chain". That's the process whereby the message and its metadata flow through rules to determine whether the post is allowed. Clearly, signature checking should occur in a rule. This will also make it easier for you to test.
The outcome of the signature checking rule is a boolean result. There will be an action associated with that. Because of the way links and rules work, the action is only taken if the rule hits. This means that I think the rule should probably return True if the message is *unsigned* and the action in that case is to jump to one of the Hold, Reject, or Discard chains (depending on a configuration variable - but we can discuss this).
If the rule misses (i.e. returns False) then it means the signature was valid and rule processing just continues on.
I know this is a little backwards, but it's probably the best match for the current rule/chain model.
Currently there are separate directories for rules and handlers. For now, it's best to follow that model.
-Barry
[*] It also creates IAddress records for any email addresses it's never seen before, but that's besides the point under discussion.

Not in GSoC scope, this is direct to Barry (and anybody else, including GSoC students of course, interested in core).
Barry Warsaw writes:
I know this is a little backwards, but it's probably the best match for the current rule/chain model.
I have a smallish problem with this model. Specifically, for a list with a maximum size, I think it's probably desirable to do any MIME part stripping *before* the size test. But this doesn't fit the chain(s) -> pipeline model AFAICS. I suspect there are probably other such cases where a bit of preprocessing would be useful, in particular if we implement a reencryption facility as Abhilash originally proposed.

On Jun 16, 2013, at 03:42 PM, Stephen J. Turnbull wrote:
It's a valid complaint. What I've suggested in the past is that a rule can do some *nondestructive* processing of a message before it makes its decision. The rule would either throw out the results of the processing (possibly leading to duplication of work) or would cache the results, e.g. in the metadata dictionary (possibly leading to a rather large pickle/in-memory data).
It's not great, but I still like the separation of concerns and the general concept that rules don't modify the message. To do otherwise introduces ordering dependency on the rules, which I really want to avoid. Ordering dependency on handlers can't be helped I think.
I'm certainly open to ideas here, especially if this becomes more prevalent.
-Barry

On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote:
FYI, on my production server (MM 2.1 - well actually 2.2+ ;) I reorder the GLOBAL_PIPELINE to put MIMEDel before Hold for exactly this reason.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hi,
On Sun, Jun 16, 2013 at 01:48:34AM +0900, Stephen J. Turnbull wrote:
<snip>
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.
Bye,
Joost
-- Ich will in euch einen neuen Geist geben; Ich werde aus eurem Fleisch das Herz aus Stein nehmen, und will euch geben ein Herz aus Fleisch. --Ez 36,2 http://mdcc.cx/ ※ http://ad1810.com/ ※ Eindhoven, .nl

Joost van Baal-Ilić writes:
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.

On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote:
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".
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:
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).
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

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.
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).
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?
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

All great questions. Let me just add this.
On Jun 28, 2013, at 01:03 PM, Stephen J. Turnbull wrote:
Another complication is that keys will probably be attached to users, but users have relationships with list across the entire Mailman installation. So if it were list owners that were responsible for key management, how does that cross list boundaries? What about lists on the same system but in different domains? Does the site admin have to delegate key management responsibilities to list owners? I can imagine some kind of attack involving a list owner who approves a member's key for one list, and then using that to attack other lists on the same system. Tricky business.
-Barry

On 06/28/2013 10:11 AM, Barry Warsaw wrote:
An OpenPGP certification of a key+userid just means that the certifier believes that the key belongs to the person who has that user ID (including the e-mail address). i think the best way to implement stephen's suggestion is that in order to be able to post to a signed-message-only list, a list member must have a key that has been certified by the list's administrator.
Note that this does *not* mean that a non-list-member whose key has been certified by the list's administrator can post. List membership and key certification are orthogonal attributes; Both should be needed (plus a valid signature on the message, of course!) before a message is passed on to such a list.
--dkg

On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote:
ok, of course you have priority here, but i don't think we're actually disagreeing :) The "simple, generic mechanism" you describe *is* key manangement as far as i'm concerned, and i think it's an excellent step. I wouldn't want the list to do much more than this, actually; we don't want to encourage the list admin to do a lot of fiddly, error-prone, list-specific work; normal public OpenPGP certifications should be able to cover that.
You're welcome to continue to lobby him to work on key management though (in public, please :-).
:)
I think this is too fine-grained, actually -- 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".
As someone who has worked on this sort of key management in other contexts (e.g. monkeysphere), the simplest mechanism is a scheduled cronjob update from the keyservers.
One step up (fancier) is to couple the cronjob (which is still necessary to check for revocations) with a key expiry script, that knows when the next key or certification will expire and check from the keyservers at that point in time.
If the cronjob is frequent enough, i don't think the fancier approach has a great cost/benefit analysis, so i would just start with the cronjob.
Consider also that a cronjob that just does "gpg --refresh" should be sufficient to pull in revocations and modifications to expiration dates, but it won't pull in new keys that might be valid. I think that's fine for starters, and the new keys can be handled by:
I also think "always" is a reasonable default policy, though some list managers may want to be able to set it to "never" if they don't want arbitrary messages sent to the list to be able to force the list software to interact with the public keyservers directly.
ok, there are two approaches i can see:
no key upload happens manually; all keys and OpenPGP certifications are fetched from the public keyservers. If a user's key isn't in the public keyservers, or the certification by the list admin hasn't been uploaded to the public keyservers are ignored.
in addition to the use of the public keyservers, direct key upload is allowed -- e.g. people can e-mail OpenPGP certificates to a special address, or can upload them to a web form. In this case, a user who doesn't want their key on the public keyservers (or an admin who doesn't want to distribute their certifications to the public keyservers) can participate; also, a mailman installation which is (for whatever reason) unable to access any of the public keyservers can still access it.
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 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.
Regards,
--dkg

Daniel Kahn Gillmor writes:
ok, of course you have priority here, but i don't think we're actually disagreeing :)
Good!
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.
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 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 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.

On 06/29/2013 12:49 AM, Stephen J. Turnbull wrote:
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:
each e-mail list has a set of "identity certifiers"
each "identity certifier" is itself an OpenPGP primary key fingerprint (or, the primary key itself).
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).
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.
getting fancier, subscription and unsubscription messages, preference-changing messages, etc, could need to be signed by a valid, certified key as well.
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.
In this model, the only special policy that is conferred upon an OpenPGP keyholder by the list administrator is "is this key one of the list's trusted identity certifiers or not?"
I hear you :)
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, since that is the default interpretation of other pre-existing OpenPGP clients that will be seeing these same certifications.
i hope this helps clarify my perspective -- i think i'm pushing for something simpler, not more complex; i think simplicity is one of the critical factors in making this stuff comprehensible to regular e-mail list administrators. Another (as you mention above) is clear, concise, and clean reporting about what is going on!
--dkg

Daniel Kahn Gillmor writes:
Yes.
Yes. Probably the primary key.
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.
"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.
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 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!

On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
It sounds to me like you're trying to use OpenPGP keys for authorization here, rather than for authentication. I think that's a mistake.
OpenPGP's so-called "web of trust" is a network of identity certifications; it does not typically include authorization information. This is limited scope is actually a feature, for (at least) three reasons:
OpenPGP certifications are typically public -- you do not always want to publish your authorization decisions.
because OpenPGP certifications are statements about identity, you can perform some reasoned inference about them (e.g. following reasonable chains of authenticated certifications) that would be much harder to do if the semantics of any given certification could potentially indicate authorization as well as authentication.
because the certifications are just statements about identity, they are easier for most users to make; this is because it is simpler to consider identity on its own than to consider both identity and authorization bundled together. More certifications means a richer pool to draw from when trying to calculate authentication.
i'm just suggesting that those roles are authorization statements about users and lists. I apologize for not knowing the official mailman terminology here, so if you can help me translate, i would be very grateful :) I think those authorization statements should *stay the same* in mailman lists that use OpenPGP as they are in mailman lists that do not use OpenPGP.
The key-to-uid binding is done by the OpenPGP keyring. this is the entire point of an OpenPGP keyring: given a signed message and a from address, can you confirm that this message really came from the stated from address?
I don't think i understand what you're saying. when Alice makes an OpenPGP certification on Bob's key ("Alice signs Bob's key"), she is explicitly binding Bob's User ID to his public key. So saying "in the absence of actually binding a UID to the key in the certification" doesn't make sense to me.
It's not surprising that these terms still confuse people; they were muddled even in the GPG documentation up until a few years ago. It's worth clarifying them explicitly:
A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not an OpenPGP certificate) that is well-formed is "syntactically valid".
a syntactically-valid key whose certifications we are willing to rely on when evaluating other keys and user IDs is a "trusted" key. This is the same thing as saying that the key has "full ownertrust".
a (key,userID) pair that has been certified by a trusted key is "valid" -- that is, we believe that the person identified by the User ID is the person who holds the specified key.
If the plan is to use GnuPG's OpenPGP keyring as a backend for this project, it's probably worth adopting the same terminology.
Why? Why not keep relying on the keyring for that? Who is going to be responsible for checking for expiration, revocation, etc? It seems like continuing to use the keyring specifically for this relationship is the simpler and cleaner.
if they're known to be dead, they should be unsusbcribed from the list :P
Most people currently make OpenPGP certifications that have no expiry -- because there is an assumption that people's identities and keys don't change very often. This is not a universal practice, but it's pretty widespread.
if that third party was the only trusted certifier for the list, the list absolutely should stop believing that the given key belongs to the given user when the certification expires. why should the list believe anything different?
Anyway, i hope this makes my perspective on this clear: i think you should be relying on OpenPGP certifications for authentication, and you should rely on your list's keyring to understand key-to-userID mappings. And keep the authentication associations (roles that relate users to lists) as they currently are in mailman.
I realize that it sounds like these suggestions are not in line with your current plans, so maybe i'm just causing noise; if you want me to step back from the discussion, please let me know -- i certainly don't want to get in the way of the project getting done.
Regards,
--dkg

Daniel Kahn Gillmor writes:
On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
A certification is a statement that "*I* know *this* key to be associated with *that* person, and only that person". Depending on the value of "I", "you" may extend different levels of trust to "that person". You're already down the rabbit hole, my dear Alice. The question is whether to eat the red mushroom. ;-)
There's no authorization information in the web of trust. The authorization decision is made on the basis of being presented a signed key; that's all Mailman has to go on. Depending on the identity of the signer *Mailman* may grant additional authorizations.
Consider the example I gave of subscription by member recommendation.
If you don't want to expose different "roles" as OpenPGP identities, don't. Nevertheless, the capability is available in OpenPGP: the identity-to-key mapping is not one-to-one.
The whole point of the suggestion is based on this fact. There's no authorization in the signatures. Mailman makes decisions about the authorization to grant based on the identity(s) of the signer(s).
Sure, but some users are smarter than the average bear, or have requirements beyond those of a typical panda.
They are. We're just confused about "user". I mean Mailman User, you mean PGP userID. They're not equivalent, at least not at the stage of adding a key to a User in Mailman.
No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because addresses are *not* Users. There is a many-to-one (address-to-User) mapping (I hope; if it's many-to-many, we can probably dodge that bullet by allowing sets of Users in many places we'd normally expect a User). However, binding an email address to a User is a Mailman operation, and at the point of adding an email to a User, in the scenario I'm thinking of the only thing Mailman has to go on is the association of a key to an email. If this is the initial email for that User, there's no problem.
But for additional emails, there *is* a problem. The identification of existing emails with the email to be added is not necessarily guaranteed by the key presented. We need to think carefully about how this works (or can be subverted).
Mailman UID != GPG UID, at least not at present, and probably not for the foreseeable future.
Not so fast. The official position of the GNU Project is that standards are optional in GNU software. We should adopt the standard terminology as used in the OpenPGP RFCs and any other non-vendor- specific documentation. If GPG pretty reliably conforms, we can use the GPG documentation as a reference since it's free and easily available.
Who said anything about not relying on the keyring? I'm saying that Mailman should not rely on the *certification* that supported adding this key, once the key is added. Unless it wants to.
In security applications, we don't rely on "shoulds," now do we?
Sure, but we're specifically discussing the case where the certification *does* expire.
Because it's the truth that the given key still does belong to the given user? And this truth is known to all subscribers of the list because each has separately authenticated that user in their personal keyrings, without expiry?
All three are fine by me, but they're not enough by themselves. One problem is associating OpenPGP userIDs with Mailman Users. They are not and cannot be the same. Another problem is associating authorizations with Users in the complex trust environment of OpenPGP.
I realize that it sounds like these suggestions are not in line with your current plans,
I don't have any plans. I'm trying to figure out what the requirements are here. The model of OpenPGP as a network of individuals, each represented by a single userID-email pair, is not a priori appropriate for mailing lists, and especially not for Mailman 3 which has many features designed for handling one User's memberships in multiple lists possibly using various email addresses across different domains typically representing different organizations.
so maybe i'm just causing noise;
No, not at all. I'm a professional in the field of drawing inferences about beliefs, but I don't know very much about OpenPGP specifically. Obviously we need to have Mailman semantics and terminology correspond to OpenPGP semantics and terminology where they are supposed to be equivalent.

On Jul 02, 2013, at 01:04 PM, Stephen J. Turnbull wrote:
You're correct, although technically addresses don't have to be associated with users. But if they are, they can only be associated with a single user. Users can control multiple addresses.
While unlinked addresses are supported by the model, I don't think there's any case where unlinked addresses are really exposed in any meaningful way that a user or admin can utilize. So I think if we can associate OpenPGP user ids to email addresses, that will almost always imply an association to a user.
Very definitely. While it's easy to associate an address with an existing user, it's not entirely clear how we can do that in a secure way.
-Barry

I am not an expert but the encryption discussion is extremely important. Are you familiar with the Secure Email Lists (SELS) project? If not, drop everything and look at it at right now
http://sels.ncsa.illinois.edu/index.html
http://www.ncsa.illinois.edu/People/hkhurana/SAC05_1.pdf
To my limited understanding it seems to have the perfect solution for mailing lists. Instead of decrypting the messages and re-encrypting them, the mailing list server simply changes the keys needed to read the message without having access to the content of the messages. For this feat to be possible, the mailing list administrator receives the keys from the subscribers and re-issues a different key to each subscriber. I.e., the mailing list administrator must be a trusted person, but the server does not have to be trusted. I think this is often the situation with mailing lists. From skimming your messages I did not have the sense that you were discussing such a paradigm. Perhaps you are discussing it and I didn't get it, or you have good reasons not to. You don't have to reply to me if I am saying something obvious or stupid. But if you are not even familiar with this approach, I urge you to look at it.
Thank you for all the great work you are doing.
Hans G Ehrbar

ehrbar@greenhouse.economics.utah.edu writes:
I am not an expert but the encryption discussion is extremely important.
We are not currently discussing encryption, but rather signing. A similar approach might work for signing, but it's subject to a weaker form of the objection below.[1]
Are you familiar with the Secure Email Lists (SELS) project?
It's been mentioned.
To my limited understanding it seems to have the perfect solution for mailing lists.
Nothing in email is perfect or as simple as it seems. :-)
From skimming your messages I did not have the sense that you were discussing such a paradigm.
We aren't. This paradigm has a serious security hole from the point of view of Mailman in that many lists consider the filtering services (ie, blocking certain MIME content-types) to be essential. Since the MTA cannot decode and Mailman doesn't decode messages, there is no way to prevent distribution of malware. This would at the very least be a serious embarrassment to the operators of the allegedly "secure" list, and in my experience a serious danger, as I know very few people who treat "secure" systems as anything but absolutely safe, ignoring the fact that any given security system can only handle the attack vectors it was designed to handle.
It might be useful to add it as an additional service, but given the responsibility that mailing list admins are expected to shoulder in today's environment, I think it's essential that the admins have access to the content distributed by their lists.
Steve
Footnotes: [1] Although filtering is possible, the approach you describe would require whole messages rather than parts to be filtered AFAICS.

Stephen's already given a very good response, so I'll just add a few more thoughts.
On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:
One thing you could do is to send a confirmation message encrypted to that public key. You'd have to make sure that the confirmation token is *only* in the encrypted part (e.g. you could not include the token in the Subject header as we currently do for convenient "just hit reply" functionality).
The point is that if Mailman has the public key, because they user just uploaded it, then the intended recipient must have the private key. If you encrypt the confirmation token to this public key, then the recipient's private key should be able to decrypt it. An evil interceptor wouldn't have that private key and thus would not be able to hijack anything.
Probably not as a first step. PGP/MIME will be easier to support so do that first. As Stephen suggests, a survey of popular MUAs might be useful. My own (Claws Mail) supports them both, though I'm not sure which is default. I certainly use and prefer PGP/MIME.
You'll want to look at the IMailingList.anonymous_list flag.
Please use python-gnupg. I've been using it lately for a different project and I think it's very solid, with a nice API. Plus, it's actively maintained by a good developer who is responsive to bugs and feature requests. Plus, it's Python 3 compatible. :)
I think it does make sense to put some primitives in a utilities/gpg.py module. The things that should go in here are probably higher level APIs that Mailman itself will find useful. Be sure that anything that goes in here has a unit test (at least) and possibly a doctest.
I'm with Stephen here, I don't think a separate queue is required. A new queue implies another runner, which means another process that must be managed. Signing isn't *that* much of a bottleneck that adding it will gum up the works too much.
I think it would be okay to sign the message once for all recipients, even if we're doing personalization. The personalized parts will have to go in the unsigned bits though (e.g. the headers and any user-specific footer parts). If not, then the outgoing signatures will have to be added by the mta component so that it signs the final message before it's sent to the upstream MTA for delivery.
-Barry

On 06/15/2013 02:45 PM, Barry Warsaw wrote:
I think Thunderbird/EnigMail uses inline pgp by default, but PGP/MIME can be set as the default per account and is always available when composing a message.
At one time EnigMail discouraged PGP/MIME as being supported by few MUAs, but that caveat appears to have been removed from the current UI.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Abhilash Raj writes:
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.
It depends on how it gets used. If there are MUAs that do this without consulting the user, then we should support it eventually. If it requires a user's guidance to get that result, then we can just tell them "Don't do that."
You should give a reference for "not best practice."
I think we should handle it. Among other things, if you want the originator headers signed, I would think the easiest way to achieve that would be to send a signed message/rfc822 part.
Needs to be an option. By default, the sender's signature should be kept so that recipients who know the sender well enough to have his key can verify it. This may also help with catching key fraud. But as you say it could be used to identify a poster, and that might be bad in some contexts.
I don't understand what you're suggesting. I think the list should be capable of signing mail itself, even if incoming mail is not signed, yes. For example, posting may only be allowed by the list owner from localhost, and signing is a convenience.
Seems reasonable as an extension if you have time.
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 think you need to study the architecture more carefully. I don't think it's appropriate for the incoming runner to be calling functions, rather there should be a Rule in the pipeline that does this checking.
Here and in the previous point I don't think you should be adding policy options yet. I don't see why we need to consider dates other than the issue of expired keys. Similarly for revoked keys, but of course we can't tell that very easily.
Similarly to the above, I don't think this should be done in the outgoing runner, but rather in the Handler pipeline.
I think the function to prase message, check signature, resign message could be there in utilities as a gpg.py module.
Maybe. Again you should check current style. I Think what you propose is OK, as Rules and Handlers can live in the same file since they are distinguished by their signatures. But I forget exactly how Barry organizes this stuff.
Queues imply storage. I don't know if we are thinking about any threat models in which the attacker could change content after validation of the poster's signature and before resigning as the list, but you want to be careful about proliferating queues.
Steve

On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote:
Right. Remember that all the incoming runner does[*] is take a message that's already been parsed, and send it through the "posting chain". That's the process whereby the message and its metadata flow through rules to determine whether the post is allowed. Clearly, signature checking should occur in a rule. This will also make it easier for you to test.
The outcome of the signature checking rule is a boolean result. There will be an action associated with that. Because of the way links and rules work, the action is only taken if the rule hits. This means that I think the rule should probably return True if the message is *unsigned* and the action in that case is to jump to one of the Hold, Reject, or Discard chains (depending on a configuration variable - but we can discuss this).
If the rule misses (i.e. returns False) then it means the signature was valid and rule processing just continues on.
I know this is a little backwards, but it's probably the best match for the current rule/chain model.
Currently there are separate directories for rules and handlers. For now, it's best to follow that model.
-Barry
[*] It also creates IAddress records for any email addresses it's never seen before, but that's besides the point under discussion.

Not in GSoC scope, this is direct to Barry (and anybody else, including GSoC students of course, interested in core).
Barry Warsaw writes:
I know this is a little backwards, but it's probably the best match for the current rule/chain model.
I have a smallish problem with this model. Specifically, for a list with a maximum size, I think it's probably desirable to do any MIME part stripping *before* the size test. But this doesn't fit the chain(s) -> pipeline model AFAICS. I suspect there are probably other such cases where a bit of preprocessing would be useful, in particular if we implement a reencryption facility as Abhilash originally proposed.

On Jun 16, 2013, at 03:42 PM, Stephen J. Turnbull wrote:
It's a valid complaint. What I've suggested in the past is that a rule can do some *nondestructive* processing of a message before it makes its decision. The rule would either throw out the results of the processing (possibly leading to duplication of work) or would cache the results, e.g. in the metadata dictionary (possibly leading to a rather large pickle/in-memory data).
It's not great, but I still like the separation of concerns and the general concept that rules don't modify the message. To do otherwise introduces ordering dependency on the rules, which I really want to avoid. Ordering dependency on handlers can't be helped I think.
I'm certainly open to ideas here, especially if this becomes more prevalent.
-Barry

On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote:
FYI, on my production server (MM 2.1 - well actually 2.2+ ;) I reorder the GLOBAL_PIPELINE to put MIMEDel before Hold for exactly this reason.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hi,
On Sun, Jun 16, 2013 at 01:48:34AM +0900, Stephen J. Turnbull wrote:
<snip>
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.
Bye,
Joost
-- Ich will in euch einen neuen Geist geben; Ich werde aus eurem Fleisch das Herz aus Stein nehmen, und will euch geben ein Herz aus Fleisch. --Ez 36,2 http://mdcc.cx/ ※ http://ad1810.com/ ※ Eindhoven, .nl

Joost van Baal-Ilić writes:
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.

On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote:
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".
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:
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).
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

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.
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).
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?
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

All great questions. Let me just add this.
On Jun 28, 2013, at 01:03 PM, Stephen J. Turnbull wrote:
Another complication is that keys will probably be attached to users, but users have relationships with list across the entire Mailman installation. So if it were list owners that were responsible for key management, how does that cross list boundaries? What about lists on the same system but in different domains? Does the site admin have to delegate key management responsibilities to list owners? I can imagine some kind of attack involving a list owner who approves a member's key for one list, and then using that to attack other lists on the same system. Tricky business.
-Barry

On 06/28/2013 10:11 AM, Barry Warsaw wrote:
An OpenPGP certification of a key+userid just means that the certifier believes that the key belongs to the person who has that user ID (including the e-mail address). i think the best way to implement stephen's suggestion is that in order to be able to post to a signed-message-only list, a list member must have a key that has been certified by the list's administrator.
Note that this does *not* mean that a non-list-member whose key has been certified by the list's administrator can post. List membership and key certification are orthogonal attributes; Both should be needed (plus a valid signature on the message, of course!) before a message is passed on to such a list.
--dkg

On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote:
ok, of course you have priority here, but i don't think we're actually disagreeing :) The "simple, generic mechanism" you describe *is* key manangement as far as i'm concerned, and i think it's an excellent step. I wouldn't want the list to do much more than this, actually; we don't want to encourage the list admin to do a lot of fiddly, error-prone, list-specific work; normal public OpenPGP certifications should be able to cover that.
You're welcome to continue to lobby him to work on key management though (in public, please :-).
:)
I think this is too fine-grained, actually -- 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".
As someone who has worked on this sort of key management in other contexts (e.g. monkeysphere), the simplest mechanism is a scheduled cronjob update from the keyservers.
One step up (fancier) is to couple the cronjob (which is still necessary to check for revocations) with a key expiry script, that knows when the next key or certification will expire and check from the keyservers at that point in time.
If the cronjob is frequent enough, i don't think the fancier approach has a great cost/benefit analysis, so i would just start with the cronjob.
Consider also that a cronjob that just does "gpg --refresh" should be sufficient to pull in revocations and modifications to expiration dates, but it won't pull in new keys that might be valid. I think that's fine for starters, and the new keys can be handled by:
I also think "always" is a reasonable default policy, though some list managers may want to be able to set it to "never" if they don't want arbitrary messages sent to the list to be able to force the list software to interact with the public keyservers directly.
ok, there are two approaches i can see:
no key upload happens manually; all keys and OpenPGP certifications are fetched from the public keyservers. If a user's key isn't in the public keyservers, or the certification by the list admin hasn't been uploaded to the public keyservers are ignored.
in addition to the use of the public keyservers, direct key upload is allowed -- e.g. people can e-mail OpenPGP certificates to a special address, or can upload them to a web form. In this case, a user who doesn't want their key on the public keyservers (or an admin who doesn't want to distribute their certifications to the public keyservers) can participate; also, a mailman installation which is (for whatever reason) unable to access any of the public keyservers can still access it.
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 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.
Regards,
--dkg

Daniel Kahn Gillmor writes:
ok, of course you have priority here, but i don't think we're actually disagreeing :)
Good!
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.
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 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 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.

On 06/29/2013 12:49 AM, Stephen J. Turnbull wrote:
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:
each e-mail list has a set of "identity certifiers"
each "identity certifier" is itself an OpenPGP primary key fingerprint (or, the primary key itself).
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).
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.
getting fancier, subscription and unsubscription messages, preference-changing messages, etc, could need to be signed by a valid, certified key as well.
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.
In this model, the only special policy that is conferred upon an OpenPGP keyholder by the list administrator is "is this key one of the list's trusted identity certifiers or not?"
I hear you :)
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, since that is the default interpretation of other pre-existing OpenPGP clients that will be seeing these same certifications.
i hope this helps clarify my perspective -- i think i'm pushing for something simpler, not more complex; i think simplicity is one of the critical factors in making this stuff comprehensible to regular e-mail list administrators. Another (as you mention above) is clear, concise, and clean reporting about what is going on!
--dkg

Daniel Kahn Gillmor writes:
Yes.
Yes. Probably the primary key.
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.
"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.
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 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!

On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
It sounds to me like you're trying to use OpenPGP keys for authorization here, rather than for authentication. I think that's a mistake.
OpenPGP's so-called "web of trust" is a network of identity certifications; it does not typically include authorization information. This is limited scope is actually a feature, for (at least) three reasons:
OpenPGP certifications are typically public -- you do not always want to publish your authorization decisions.
because OpenPGP certifications are statements about identity, you can perform some reasoned inference about them (e.g. following reasonable chains of authenticated certifications) that would be much harder to do if the semantics of any given certification could potentially indicate authorization as well as authentication.
because the certifications are just statements about identity, they are easier for most users to make; this is because it is simpler to consider identity on its own than to consider both identity and authorization bundled together. More certifications means a richer pool to draw from when trying to calculate authentication.
i'm just suggesting that those roles are authorization statements about users and lists. I apologize for not knowing the official mailman terminology here, so if you can help me translate, i would be very grateful :) I think those authorization statements should *stay the same* in mailman lists that use OpenPGP as they are in mailman lists that do not use OpenPGP.
The key-to-uid binding is done by the OpenPGP keyring. this is the entire point of an OpenPGP keyring: given a signed message and a from address, can you confirm that this message really came from the stated from address?
I don't think i understand what you're saying. when Alice makes an OpenPGP certification on Bob's key ("Alice signs Bob's key"), she is explicitly binding Bob's User ID to his public key. So saying "in the absence of actually binding a UID to the key in the certification" doesn't make sense to me.
It's not surprising that these terms still confuse people; they were muddled even in the GPG documentation up until a few years ago. It's worth clarifying them explicitly:
A literal key (nothing but a key, no UIDs, no self-sigs, etc -- not an OpenPGP certificate) that is well-formed is "syntactically valid".
a syntactically-valid key whose certifications we are willing to rely on when evaluating other keys and user IDs is a "trusted" key. This is the same thing as saying that the key has "full ownertrust".
a (key,userID) pair that has been certified by a trusted key is "valid" -- that is, we believe that the person identified by the User ID is the person who holds the specified key.
If the plan is to use GnuPG's OpenPGP keyring as a backend for this project, it's probably worth adopting the same terminology.
Why? Why not keep relying on the keyring for that? Who is going to be responsible for checking for expiration, revocation, etc? It seems like continuing to use the keyring specifically for this relationship is the simpler and cleaner.
if they're known to be dead, they should be unsusbcribed from the list :P
Most people currently make OpenPGP certifications that have no expiry -- because there is an assumption that people's identities and keys don't change very often. This is not a universal practice, but it's pretty widespread.
if that third party was the only trusted certifier for the list, the list absolutely should stop believing that the given key belongs to the given user when the certification expires. why should the list believe anything different?
Anyway, i hope this makes my perspective on this clear: i think you should be relying on OpenPGP certifications for authentication, and you should rely on your list's keyring to understand key-to-userID mappings. And keep the authentication associations (roles that relate users to lists) as they currently are in mailman.
I realize that it sounds like these suggestions are not in line with your current plans, so maybe i'm just causing noise; if you want me to step back from the discussion, please let me know -- i certainly don't want to get in the way of the project getting done.
Regards,
--dkg

Daniel Kahn Gillmor writes:
On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
A certification is a statement that "*I* know *this* key to be associated with *that* person, and only that person". Depending on the value of "I", "you" may extend different levels of trust to "that person". You're already down the rabbit hole, my dear Alice. The question is whether to eat the red mushroom. ;-)
There's no authorization information in the web of trust. The authorization decision is made on the basis of being presented a signed key; that's all Mailman has to go on. Depending on the identity of the signer *Mailman* may grant additional authorizations.
Consider the example I gave of subscription by member recommendation.
If you don't want to expose different "roles" as OpenPGP identities, don't. Nevertheless, the capability is available in OpenPGP: the identity-to-key mapping is not one-to-one.
The whole point of the suggestion is based on this fact. There's no authorization in the signatures. Mailman makes decisions about the authorization to grant based on the identity(s) of the signer(s).
Sure, but some users are smarter than the average bear, or have requirements beyond those of a typical panda.
They are. We're just confused about "user". I mean Mailman User, you mean PGP userID. They're not equivalent, at least not at the stage of adding a key to a User in Mailman.
No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because addresses are *not* Users. There is a many-to-one (address-to-User) mapping (I hope; if it's many-to-many, we can probably dodge that bullet by allowing sets of Users in many places we'd normally expect a User). However, binding an email address to a User is a Mailman operation, and at the point of adding an email to a User, in the scenario I'm thinking of the only thing Mailman has to go on is the association of a key to an email. If this is the initial email for that User, there's no problem.
But for additional emails, there *is* a problem. The identification of existing emails with the email to be added is not necessarily guaranteed by the key presented. We need to think carefully about how this works (or can be subverted).
Mailman UID != GPG UID, at least not at present, and probably not for the foreseeable future.
Not so fast. The official position of the GNU Project is that standards are optional in GNU software. We should adopt the standard terminology as used in the OpenPGP RFCs and any other non-vendor- specific documentation. If GPG pretty reliably conforms, we can use the GPG documentation as a reference since it's free and easily available.
Who said anything about not relying on the keyring? I'm saying that Mailman should not rely on the *certification* that supported adding this key, once the key is added. Unless it wants to.
In security applications, we don't rely on "shoulds," now do we?
Sure, but we're specifically discussing the case where the certification *does* expire.
Because it's the truth that the given key still does belong to the given user? And this truth is known to all subscribers of the list because each has separately authenticated that user in their personal keyrings, without expiry?
All three are fine by me, but they're not enough by themselves. One problem is associating OpenPGP userIDs with Mailman Users. They are not and cannot be the same. Another problem is associating authorizations with Users in the complex trust environment of OpenPGP.
I realize that it sounds like these suggestions are not in line with your current plans,
I don't have any plans. I'm trying to figure out what the requirements are here. The model of OpenPGP as a network of individuals, each represented by a single userID-email pair, is not a priori appropriate for mailing lists, and especially not for Mailman 3 which has many features designed for handling one User's memberships in multiple lists possibly using various email addresses across different domains typically representing different organizations.
so maybe i'm just causing noise;
No, not at all. I'm a professional in the field of drawing inferences about beliefs, but I don't know very much about OpenPGP specifically. Obviously we need to have Mailman semantics and terminology correspond to OpenPGP semantics and terminology where they are supposed to be equivalent.

On Jul 02, 2013, at 01:04 PM, Stephen J. Turnbull wrote:
You're correct, although technically addresses don't have to be associated with users. But if they are, they can only be associated with a single user. Users can control multiple addresses.
While unlinked addresses are supported by the model, I don't think there's any case where unlinked addresses are really exposed in any meaningful way that a user or admin can utilize. So I think if we can associate OpenPGP user ids to email addresses, that will almost always imply an association to a user.
Very definitely. While it's easy to associate an address with an existing user, it's not entirely clear how we can do that in a secure way.
-Barry

I am not an expert but the encryption discussion is extremely important. Are you familiar with the Secure Email Lists (SELS) project? If not, drop everything and look at it at right now
http://sels.ncsa.illinois.edu/index.html
http://www.ncsa.illinois.edu/People/hkhurana/SAC05_1.pdf
To my limited understanding it seems to have the perfect solution for mailing lists. Instead of decrypting the messages and re-encrypting them, the mailing list server simply changes the keys needed to read the message without having access to the content of the messages. For this feat to be possible, the mailing list administrator receives the keys from the subscribers and re-issues a different key to each subscriber. I.e., the mailing list administrator must be a trusted person, but the server does not have to be trusted. I think this is often the situation with mailing lists. From skimming your messages I did not have the sense that you were discussing such a paradigm. Perhaps you are discussing it and I didn't get it, or you have good reasons not to. You don't have to reply to me if I am saying something obvious or stupid. But if you are not even familiar with this approach, I urge you to look at it.
Thank you for all the great work you are doing.
Hans G Ehrbar

ehrbar@greenhouse.economics.utah.edu writes:
I am not an expert but the encryption discussion is extremely important.
We are not currently discussing encryption, but rather signing. A similar approach might work for signing, but it's subject to a weaker form of the objection below.[1]
Are you familiar with the Secure Email Lists (SELS) project?
It's been mentioned.
To my limited understanding it seems to have the perfect solution for mailing lists.
Nothing in email is perfect or as simple as it seems. :-)
From skimming your messages I did not have the sense that you were discussing such a paradigm.
We aren't. This paradigm has a serious security hole from the point of view of Mailman in that many lists consider the filtering services (ie, blocking certain MIME content-types) to be essential. Since the MTA cannot decode and Mailman doesn't decode messages, there is no way to prevent distribution of malware. This would at the very least be a serious embarrassment to the operators of the allegedly "secure" list, and in my experience a serious danger, as I know very few people who treat "secure" systems as anything but absolutely safe, ignoring the fact that any given security system can only handle the attack vectors it was designed to handle.
It might be useful to add it as an additional service, but given the responsibility that mailing list admins are expected to shoulder in today's environment, I think it's essential that the admins have access to the content distributed by their lists.
Steve
Footnotes: [1] Although filtering is possible, the approach you describe would require whole messages rather than parts to be filtered AFAICS.

Stephen's already given a very good response, so I'll just add a few more thoughts.
On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:
One thing you could do is to send a confirmation message encrypted to that public key. You'd have to make sure that the confirmation token is *only* in the encrypted part (e.g. you could not include the token in the Subject header as we currently do for convenient "just hit reply" functionality).
The point is that if Mailman has the public key, because they user just uploaded it, then the intended recipient must have the private key. If you encrypt the confirmation token to this public key, then the recipient's private key should be able to decrypt it. An evil interceptor wouldn't have that private key and thus would not be able to hijack anything.
Probably not as a first step. PGP/MIME will be easier to support so do that first. As Stephen suggests, a survey of popular MUAs might be useful. My own (Claws Mail) supports them both, though I'm not sure which is default. I certainly use and prefer PGP/MIME.
You'll want to look at the IMailingList.anonymous_list flag.
Please use python-gnupg. I've been using it lately for a different project and I think it's very solid, with a nice API. Plus, it's actively maintained by a good developer who is responsive to bugs and feature requests. Plus, it's Python 3 compatible. :)
I think it does make sense to put some primitives in a utilities/gpg.py module. The things that should go in here are probably higher level APIs that Mailman itself will find useful. Be sure that anything that goes in here has a unit test (at least) and possibly a doctest.
I'm with Stephen here, I don't think a separate queue is required. A new queue implies another runner, which means another process that must be managed. Signing isn't *that* much of a bottleneck that adding it will gum up the works too much.
I think it would be okay to sign the message once for all recipients, even if we're doing personalization. The personalized parts will have to go in the unsigned bits though (e.g. the headers and any user-specific footer parts). If not, then the outgoing signatures will have to be added by the mta component so that it signs the final message before it's sent to the upstream MTA for delivery.
-Barry

On 06/15/2013 02:45 PM, Barry Warsaw wrote:
I think Thunderbird/EnigMail uses inline pgp by default, but PGP/MIME can be set as the default per account and is always available when composing a message.
At one time EnigMail discouraged PGP/MIME as being supported by few MUAs, but that caveat appears to have been removed from the current UI.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (7)
-
Abhilash Raj
-
Barry Warsaw
-
Daniel Kahn Gillmor
-
ehrbar@greenhouse.economics.utah.edu
-
Joost van Baal-Ilić
-
Mark Sapiro
-
Stephen J. Turnbull