On 04/24/2014 03:12 PM, Rob Browning wrote:
> [If possible, please preserve the 745553-forwarded address in any replies.]
> 
> This bug was filed recently, and I suspect it might be something you'd
> like to discuss upstream.

thanks for forwarding this, Rob.

More notes below:

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
 [...]
>> Consider Alice, who has OpenPGP certificates for "Bob
>> <bob@example.org>" and "Carol <carol@example.org>" in her keyring (in
>> that order).  She has certified them both, so there is one valid
>> primary key for bob@example.org and one valid primary key for
>> alice@example.org.
>>
>> Bob turns evil (or maybe his key is compromised) and he adds a new
>> User ID: "Bob <carol@example.org>" to his OpenPGP cert.  He publishes
>> the update to the keyservers.
>>
>> Alice, following best practices, updates her keyring from the
>> keyservers regularly.
>>
>> Alice's keyring now has two certs that have a "carol@example.org" user
>> ID in them.  One of them is valid, and the other one is not.
>>
>> Alice now composes a message to "Carol <carol@example.org>" and marks
>> it with:
>>
>>  <#secure method=pgpmime mode=signencrypt>
>>
>> As the message goes out, mml-mode just passes the e-mail address
>> carol@example.org to gpg to encrypt the message body, and gpg uses the
>> e-mail address to select a key.  Since Bob's key is first in the
>> keyring, it is the one that will be used.

Turns out the situation is slightly worse than i described above.  While
i still think that mml2015-always-trust should default to nil (and this
defends against some failure modes), there are other problems with key
selection that aren't fixed yet.

In particular, the problematic scenario described above is *not* fixed
by changing the setting.  Observing the behavior, it looks like mml-mode
does OpenPGP certificate selection by e-mail address in the following
way (sorry i haven't dug into the code yet):

 0) it asks GnuPG for a cert associated with the given e-mail address

 1) it checks the *overall* validity of the cert in order to decide if
the cert is the right one

 2) if the cert is valid, it encrypts to it.

The problem with this is how gpg defines the overall validity of the
cert: in particular, it defines the validity of a cert as the *highest*
validity of any UserID associated with the cert.  It should instead be
looking at the validity of the desired User ID specifically, not the
overall cert.

So in the scenario above, Bob's cert is still overall valid (because it
has a valid certification over the correct UserID+key from Alice), even
though the carol@example.org UserID is invalid.

I don't know mml-mode or elisp well enough to dig into the code and fix
this part of the problem quickly, but if someone has patches that i can
look at that would point to where it might be changed, i'd be happy to
try to review them.

	--dkg