Page MenuHome GnuPG

Libkleo Keyresolver: check for existing encryption subkey instead valid one, as first step
Closed, ResolvedPublic

Description

Try to send an encrypted mail to an address where the OpenPGP key has expired. (Or to a keygroup, where one of the keys has expired). The Confirmation dialog comes up:

Even if you remove the filter, the address in question is not listed at all, not even as "not compliant".
This is now a different behavior than for S/MIME keys, for which we do now offer the option to encrypt anyway, though it is not compliant.

And in case of keygroups we have the additional difficulty that it would be preferable to encrypt at least to the valid keys of the group, instead of not showing no key for the recipient and no hint for the user what the problem may be.
Here I would at least expect some helpful error message regarding the reason if we do not allow the encryption to that group.

See also T6742.

Update: "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address. If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

In case of a key group this has the consequence that the keys in the group will be resolved and the user can decide if the message should be encrypted to the remaining, not expired keys only.

Details

Version
VS-Desktop-3.2.0.0-beta229/231

Event Timeline

aheinecke wrote regarding not showing the group at all (https://dev.gnupg.org/T6401#175847):

I think from a users standpoint that is too intransparent. The user needs to see that there is a group there and that this group has a certificate in it that is problematic, only then they can start to somehow try to remedy that situation by asking for an updated key for that user for example. Just skipping the whole group is confusing in that case. And leads the user to think that there is a bug or problem with the software and not with the certificate group configuration.

With https://dev.gnupg.org/T6701 you can now even encrypt to an expired or even revoked S/MIME certificate if you chose to do so. I have to test if that is the case with --always-trust in OpenPGP, too. Then I could basically place the same error handling there. Another alternative would then be to not to encrypt to this specific key by chosing the option from the combobox, so all the people with "correct" keys in the group will get the mail but the one person who has for example the expired key will not be able to decrypt the mail. This moves the problem then from the senders side who can now still encrypt to most of the group, to the receivers side with the e.g. expired key to send / publish around an updated key to all the people they want to keep in touch with.

So I would prefer if groups that are not fully acceptable would also be expanded for OpenPGP too.

again aheinecke:

I think as long as we ensure that an expired key is never preferred in the sort order we should show it, at least to make the problem discoverable and then even allow to "Force" encryption even to that expired key, like we now have for S/MIME with T6559 although that works a bit differently, for S/MIME in GpgOL i first try to encrypt, and if that fails I bring up the error dialog and then ask the user "Do you want to try harder" ("WARNING: This is not VS-NfD compliant.") And I think if you really want to encrypt something it is better to send something to an expired key because you likely just have not received the update. As the alternative is usually to not encrypt at all because it is to difficult. So while I hate message boxes that users tend to ignore anyway, I think we should show expired / revoked keys before we don't show any keys at all.

TBH when I look at the code I think its an unintended side effect that expired keys are not shown.

I left this comment there:

/* Also list unusable keys to make it transparent why they are unusable */

And apparently this filters out expired / revoked keys:

> class OpenPGPFilter : public DefaultKeyFilter
> {
> public:
>     OpenPGPFilter()
>         : DefaultKeyFilter()
>     {
>         setIsOpenPGP(DefaultKeyFilter::Set);
>         setCanEncrypt(DefaultKeyFilter::Set);
>     }
> };

While this does not:

> class SMIMEFilter : public DefaultKeyFilter
> {
> public:
>     SMIMEFilter()
>         : DefaultKeyFilter()
>     {
>         setIsOpenPGP(DefaultKeyFilter::NotSet);
>         setCanEncrypt(DefaultKeyFilter::Set);
>     }
> };
ebo mentioned this in Unknown Object (Maniphest Task).Oct 2 2023, 1:53 PM

See also https://dev.gnupg.org/T6401#176099 which explains why OpenPGP seems to behave differently than S/MIME.

aheinecke added a subscriber: aheinecke.

So I think we need to somehow show this. This gives users the option not to encrypt to the one or two expired keys and maybe ask them from updated keys or continue the operation anyway. (Although I am unsure if gpg would not throw an error in that case even with trust model always). From a User Experience standpoint I think we need to make it visible that you had a key for a person once but that this key is expired now. Regardless of wether or not it should then still be used. The "No Key" is a bit of a wrong information here. So show such keys as the first entries and then disable the ok button until the user somehow solves the issue.

It is is somewhat more clear with revoked. With OpenPGP we know before starting the encryption if a key is revoked. In that case we should maybe show the revoked key but disable the encrypt button. I think gnupg also won't allow it. Assuming that if a user made sure you received their revoked key they really don't want you to send encrypted files to that anymore.

That is a different behavior for S/MIME though because the ALWAYS_ENCRYPT feature was explicitly added for the multitude of problems that comes with CRL checking. So there I just show the error why GnuPG failed to encrypt the message and then tries again with ALWAYS_TRUST. If the user confirms that this error should be ignored.

We discussed and decided that "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address.

If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

In case of a key group this has the consequence that the keys in the group will be resolved and the user can decide if the message should be encrypted to the remaining, not expired keys only.

ebo renamed this task from Libkleo Keyresolver: Allow to send to expired key? to Libkleo Keyresolver: check for existing encryption subkey instead vaild one, as first step.Oct 5 2023, 12:38 PM
ebo updated the task description. (Show Details)

With the above changes a group with an expired key is now expanded. But, as in T6742, the key is shown with the blue info icon instead of with a red X icon and the OK button is enabled.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker renamed this task from Libkleo Keyresolver: check for existing encryption subkey instead vaild one, as first step to Libkleo Keyresolver: check for existing encryption subkey instead valid one, as first step.Oct 13 2023, 9:28 AM
ikloecker changed the task status from Open to Testing.Oct 13 2023, 10:24 AM
ikloecker removed ikloecker as the assignee of this task.

The issue should be fixed, i.e.

  • groups containing only encryption-capable certificates (i.e. they have an encryption subkey) are expanded
  • certificates which cannot be used for encryption because they (or just the encryption subkeys) are revoked or expired or otherwise invalid are marked with the error marker
  • the OK button is disabled if any invalid encryption certificate is selected
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 31 2023, 9:29 AM
ebo claimed this task.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ebo added a project: vsd32 (vsd-3.2.0).

Works with VS-Desktop-3.1.90.277-Beta