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

[Andre Heinecke]

Hi,

On Monday 31 October 2016 13:12:16 Justus Winter wrote:
> When a name resembling a mail address is given to either --locate-key
> or --recipient, rank the search results and use only the most relevant
> key.

I would prefer it if this function would also return expired / revoked / 
validitity never etc. Keys. So in a GUI we could handle this case by informing 
the user that the key for this user is expired.

Otherwise we would have to check for that case with another keylisting to 
avoid the problem that a user was able to encrypt to someone yesterday 
automatically and today it no longer works and the UI just shows "No key for 
this recipient" when a UI uses locate-keys.

> This also lets us query which key will be used for encryption using
> --locate-key.  XXX: Is this true?  B/c if we use --recipient, we only
> consider keys usable for encryption. Otoh, --locate-key has no such
> constraint.

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.


Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161031/8435a16b/attachment-0001.sig>