[PATCH GnuPG] RFC: g10: Improve and unify key selection.

[Daniel Kahn Gillmor]

On Mon 2016-10-31 10:51:29 -0400, Andre Heinecke wrote:
> I think this could be solved by ranking a key that can both encrypt higher 
> then a key that can't encrypt. This would avoid the state where an encrypt key 
> can can't be found because a user has a different primary key with only signing 
> (for whatever weird reason). The primary usecase of this function imo is to 
> look up recipient keys for encryption.

If this is the use case, we should be explicit about it in the function
naming and/or arguments.  It's conceivable that someone might want to
use this search for other purposes, and we should make it clear that
it's encryption focused.

Other possible uses:

 * what key to use when verifying a signature?  Most signatures already
   indicate which key made them, so you'd find the signing key to verify
   directly from the signature; we don't need to look up the key by
   e-mail address or user ID in this case.  so this one is probably not
   relevant.

 * what key(s) to permit for authentication based on a particular user
   ID?  (e.g. monkeysphere) In practice, we might want a list of *all*
   keys that have a given validity-level and have an
   authentication-capable subkey.  So this one might be relevant, and it
   would be nice to know that you'd be returned the keys in order of
   validity, so you could just stop parsing the list when the validity
   drops below the level that you care about.

Anything else?

         --dkg