For testing with file encryption and notepad you can use this chain which is valid but does not provide a valid CRL for us

In T6702#176858, @aheinecke wrote:

We should probably also check KMail though. There might be a similar fix needed although there I am unsure if the old keyresolver does not do a crl check when a certificate is selected.

Not sure about S/MIME, but for OpenPGP I'm pretty sure that a check is done when a certificate is selected in the old approval dialog (resp. in the key chooser opened from this dialog).

We need to test the current state

Do we have a test certificate for this? The certificate in T6702#176845 is expired.

It needs to be clarified which kind of errors should be handled and which kind of S/MIME certificates should be allowed to be used for encryption:

• Valid certificates where the CRL check (or OCSP check?) fails
• Invalid certificates (e.g. because of incomplete chain/missing CA)
• Expired certificates

Currently, Kleopatra doesn't even allow to start/attempt encryption for certificates which are not valid. Allowing invalid or expired certificates will require massive changes.

Maybe those smime certs will do:

• broken: inaccessible url crlDistributionPoints = URI:http://gnupg.test/crl.pem
  
  
  bob-brokenCrlDP.p124 KBDownload

• invalid: invalid content crlDistributionPoints = URI:https://gnupg.com/share/g10code-key.asc
  
  
  bob-invalidCrlDP.p124 KBDownload

In my tests, both have the same behavior:

• invalid after opening the details, so the cert can't be chosen for file encryption afterwards
• if chosen before invalidation, it hangs indefinitely on file encryption (will create another ticket for this)

According to Werner, that should be:

It needs to be clarified which kind of errors should be handled and which kind of S/MIME certificates should be allowed to be used for encryption:

• Valid certificates where the CRL check (or OCSP check?) fails
• Invalid certificates (e.g. because of incomplete chain/missing CA)
• Expired certificates

Ticket for the hang on file encryption: T8187: Kleopatra: File encryption with invalid S/MIME certificate hangs indefinitely

@ebo and me talked about this and T6701: GpgOL: Use GPGME_ENCRYPT_ALWAYS_TRUST. We think, it's best to have a short meeting to discuss further changes.

There are currently two issues here (for both GpgOL and Kleopatra), which might have been mixed:

1. Handling of errors (=broken CRL check for smime certs) with an easy way to "process anyway" (the original main issue of this ticket)
2. A general wish to force the encryption for certain disallowed smime and pgp certs (expired, invalid, etc) (most important usecase: sending mails / encrypting files to recipients with temporarily expired cert or missing intermediate/root certs)

Issue 1)

• was implemented in GpgOL
  • but doesn't seem to work (at least for my test certs), see T8190: GpgOL: Encrypt/Sign issues using S/MIME certs with invalid crlDP
  • only for encryption, not signature (not clear to me, why not for both)
• should still be implemented in Kleopatra in the same way it works in GpgOL (on CRL error: Dialog to retry with lower security checks = force flag)

Issue 2) should be a new ticket and needs to be specified

• current state of offered certs in
  • GpgOL (security dialog)
    • "sign as": expired/revoked/disabled not offered, invalid forbidden
    • "encrypt to": all offered, invalid/disabled/expired/revoked forbidden (ok button disabled)
  • Kleopatra (tested with sign/encrypt file, probably the same for notepad/etc)
    • all offered (tedious, but possible via "show certificate list"), invalid/disabled/expired/revoked forbidden (OK button disabled)
• to enable a "process anyway (i know, what i'm doing)" workflow in both Kleopatra/GpgOL, i suggest
  • on forbidden certs (probably only invalid/expired/disabled, not revoked?) add a checkbox ~"lower security" (with more explanation in the tooltip) next to the disabled OK button, which reenables the OK button and adds the "force" flag (also possible for pgp?)
  • maybe an additional warning/confirmation dialog, if the checkbox was checked
  • add a registry setting to disable this checkbox (as some admins might not want to enable their users to do this)
  • Kleopatra
    • maybe readd those forbidden certs to the default dropdown list (or keep that way as incentive to fix the problem)
    • maybe only add the checkbox for smime certs, if that's easier (as pgp certs can be easily extended)
  • GpgOL
    • add the forbidden certs to "sign as" as well (probably the sender also wants to force this temporarily)
    • ensure, that the security dialog is shown, if a forbidden cert is chosen (probably already works that way?)

Issue 1) should be implemented as already described (on error -> dialog to retry with "always trust" flag)

Issue 2) moved to new issue T8193: Add a workflow to force encryption/signature with invalid or expired certificates

Current implementation for the case of an S/MIME certificate which turns out to be invalid when it's used for encryption. Is that what we want?

Possible improvements:

• The "Encrypt Notepad (Not VS-NfD Compliant)" button should probably be red like the action button of the notepad if an invalid certificate is selected.
• Show better error than "unknown host", i.e. something like "CRL check failed" or "Certificate validity check failed", but I'm not sure we get better information from gpgsm.

Feel free to suggest better texts, etc.

yes, basically it's what we want.

But the error message is really, really awful. From your suggestions I'd prefer the first one, "CRL check failed".
Maybe @pl13 can have a look at what info gpgsm can give us?

Regarding the button: yes, red for consistency would be good.
And shouldn't the certificate change from green check mark to red X after the CRL check, too? Or maybe now a blue ! because we now allow the encryption with caveats?

Ideally the certificate would change, but Kleopatra has no idea that this certificate turned out to be not valid. In fact, Kleopatra doesn't even know that the encryption failed because of some certificate. It could have failed for any other reason (e.g. full disk). Kleopatra only knows that an error occurred and offers to retry with lower security. (I looked at GpgOL and it does the same.)

Hmm, maybe Kleopatra could get some info from the encryption result. It seems to have a list of invalid recipients.

I tried to add the list of invalid recipients to the message box, but it seems that gpgsm stops the validation of the certificates at the first invalid recipient. I got only the first Bob certificate reported as invalid recipient when I tried to encrypt to both Bob certificates so that it doesn't make sense to list the (incomplete) list of invalid recipients. It also means that Kleopatra cannot update the invalid recipient certificates because it knows only of one invalid certificate.

We could validate the recipient certificates the user has chosen in the background (before they click "Encrypt"), but that's a different story.

The best option seems to be to replace the first line with the not-very-helpful error message with something like this: "Failed to encrypt the notepad because some certificates could not be validated."

Your suggestion sounds ok to me, maybe with a slight change for the message: "Failed to encrypt the notepad because at least on certificate could not be validated."

Do I understand it correctly that you found out how you can get the info that validation failed? So that you can in fact differentiate between invalid certificate and e.g. full disk?

Maybe. EncryptionResult has a list of invalid recipients and I've changed the code to show the Retry dialog only if there's at least one invalid recipient.