Re 2.:

• I think expired user IDs should also be offered. Otherwise, people who forgot to extend the validity of their certificate won't find their certificate. Usability-wise it's better to offer the certificate and show a notice that the selected certificate has expired. I wouldn't differentiate between primary and additional user IDs.

Re 3.:

• I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.
• For me user IDs are aliases. I think the notion of "primary user ID" is misleading. Often all user IDs are equally "important". And depending on context one of the non-primary user IDs may be more relevant (e.g. when receiving a signed email the user ID matching the sender address is the most relevant one). If I want to select an encryption key for encrypting something for ada@example.net then I don't want to remember that I have to look for the key lovelace@example.com. For my own keys I may be able to remember this, but not for other keys.
• "Hiding" the information about additional user IDs in a tool tip isn't a good solution because tool tips have very bad accessibility:
  • People who are not using a mouse never see tool tips, e.g. people with mobility impairments or people using a touch device.
  • People using screen readers may have turned those off by default.
  • People with cognitive and intellectual disabilities will have problems making use of the information in tool tips.
• I fail to see a reason why the selection of the key for signing is different from the selection of the key for encryption (to self). It will be very confusing if I can select my secondary user ID in the signing drop-down but cannot find it in the encryption drop-down.
• Last but not least, I don't see any disadvantages of offering all not revoked user IDs while I see many advantages for usability and accessibility.

rere 2: I agree as long as the expired certs are order behind regular certs.

rere 3: Selecting the signer key by userid allows gpg to put the Signer's UID into the signature. However, given how Kleopatra work, the signer is always specified by fingerprint and thus this does not work in this case. I am not sure whether kleopatra uses gpgme_set_sender to explicitly set the user ID. At least GpgOL should do that.

The primary user ID is important becuase if you specify a key not by fingerprint the primary user ID is used to select the preferences. The preferences may differ by user id.

I agree to the accessibility thing.

I agree with Ingo and Werner here. In summary

• Hide revoked user ids
• Show expired certs
• Sort expired certs behind regular certs

I am not sure whether kleopatra uses gpgme_set_sender to explicitly set the user ID.

Sounds like something we should do; but material for a different task

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

At the moment they are treated differently. In the dropdown for encrypt-to-self no expired certificates are listed. encrypt-to-others does not have a dropdown. You are not able to find an expired Certificate by typing the name. But you can open the certificate list to chose from, where expired certificates are shown and selectable. But when you select an expired certificate, you won't be able to select Sign/Enrypt: "Error: No matching certificates or groups found"

In T7183#188348, @ebo wrote:

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

At the moment they are treated differently. In the dropdown for encrypt-to-self no expired certificates are listed. encrypt-to-others does not have a dropdown. You are not able to find an expired Certificate by typing the name. But you can open the certificate list to chose from, where expired certificates are shown and selectable.

FWIW, I don't think that difference in behavior is intended.

This behavior of the encrypt-to-others input field is intended. It avoids "Multiple matching certificates or groups found" errors if there is one current (good) certificate and one (or more) old expired certificates for an email address. There's a button to open a dialog listing all certificates so that the user can find a certificate they are missing in the input list's completion list. I think this is an acceptable compromise between making all certificates discoverable (even expired or revoked ones) and offering not too many irrelevant certificates. When the user selects a bad certificate in the selection dialog we should probably show a note that this certificate cannot be used instead of showing "Error: No matching certificates or groups found".

We could use the same approach for the drop-down boxes, i.e. offer only good keys/user IDs and add a button to open a dialog listing all signing/encryption keys/user IDs of the user.

ok, I like your proposal. To recap:

• show all valid (not revoked and not expired) User-Ids in the existing drop down lists
• add a button on the right side of the drop down to choose from the certificate list
• in case a revoked or expired certificate is selected, give a better error

For the latter I propose "Error: The selected certificate is not valid"

Backported for VSD 3.3