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: Draft: Add a workflow to force encryption/signature with invalid or expired certificates