[PATCH GnuPG] RFC: g10: Improve and unify key selection.
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Oct 31 17:29:04 CET 2016
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
* 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.
More information about the Gnupg-devel