GpgOL: Improve handling for always sign, when no S/MIME sec key is available
Open, HighPublic

Description

When a user starts from scratch in the configuration:

  • Prefer S/MIME
  • Always sign

He currently will be offered to generate an OpenPGP key when sending the first mail.

This is bad as it might confuse users a lot. As this is the first point of contact for probably many users we need to handle this nicely. A user might want to ignore the dialog, might not know about GpgOL and get angy.

I'm not sure about the solution. The main question is -> should we silently "not sign" in that case or should we warn and if we warn, how aggressive do we want to do this.

As we are limited what we can do in GpgOL itself I think that another gpg4win-tool is in order for this. Putting it into the keyapproval dialog would not be that helpful I think as this is more GpgOL specific.

My proposal is to:

Create a new dialog with a small text:

"GpgOL is configured to cryptographically sign all mails usign S/MIME. A secret key is required for this."

Two large buttons below (similar to kleo first start) with "Import" and "Generate".
Generate would check if all required info for the CSR can be obtained through configuration if so it
will just start to generate, show a progress and exit afterwards, showing a mail window with
the CSR addressed to the configured CA. If the CA is not configured it would show an additional
message.

We can make this feature also available through the GpgOL options or when a certificate is expired.

The closing buttons of the dialog would be:
"Send messages unsigned" "Cancel sending"

Import of a secret key would open close the dialog and continue the certificate resultion.

"Send messages unsigned" will disable this warning for the next 30 mails. After thirty mails the warning will show up again. We can also make this configurable.

Prio High because we currently have a large institution hitting this.

Details

Version
2.3.3
aheinecke created this task.May 6 2019, 5:09 PM

Mmh no. This needs to go into the resolver. If autoresolve is disabled we also want to have that functionality. Having the ca config in libkleo would also help to use the same values in Kleopatra for a CSR.