Page MenuHome GnuPG

Draft: Add a workflow to force encryption/signature with invalid or expired certificates
Open, NormalPublic

Description

split from T6702: Kleopatra: Use GPGME_ENCRYPT_ALWAYS_TRUST

Usecase:

  • Users should be able to use invalid/expired/disabled certificates for both signature/encryption
  • Invalid: users might have an S/MIME cert for a recipient, but not the root/intermediate certificate, and still need to send information
  • Expired: especially renewal of S/MIME certificates might take a while, but also pgp recipients might have forgotten to extend or publish their extended cert
  • Disabled: could be temporarily enabled, but as it's easy to implement, it can be easily used once that way without the need to use the CLI There is (and will be) no gpg option for this.

Current state of offered pgp/smime certs:

  • GpgOL (security dialog)
    • "sign as": expired/revoked/disabled not offered, invalid forbidden (OK button disabled)
    • "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 (via "show certificate list"), invalid/disabled/expired/revoked forbidden (OK button disabled)

Implementation:

  • gpg
    • a "force/ignore-expiration" flag is needed, which also permits using expired certs
  • Kleopatra and GpgOL
    • add a checkbox "Lower Security" ("Sicherheit verringern") next to the disabled OK button
      • should only be displayed, if a forbidden cert (only invalid/expired, not revoked or disabled) is selected
      • tooltip should show more explanation for the implications (especially vs-nfd compliance)
      • if checked
        • the OK button should be re-enabled (which adds the "always-trust or ignore-expiration" flag; needs the latter flag implemented in gpg) -> T8195: Add option --ignore-expiration to gpg and gpgsm
        • on OK, an additional warning/confirmation dialog with an explanation of the implication should be displayed
    • add a registry setting flag to disable this checkbox (as some admins might not want to enable their users to do this)
  • Kleopatra
    • the difficulty to add forbidden certs is intentional (to incentivise the proper fix of the problem, e.g. cert renewal)
  • GpgOL
    • add the forbidden certs (only invalid/expired, not revoked/disabled) to "sign as" as well
    • ensure, that the security dialog is shown, if a forbidden cert is chosen (probably already works that way)
    • ideally on "reply all", the forbidden certs should be preselected in the security dialog

Event Timeline

timegrid triaged this task as Normal priority.Thu, Mar 26, 3:31 PM
timegrid created this task.
timegrid created this object with edit policy "Contributor (Project)".

Invalid and expired are different cases.

--always-trust is the option for encryption to keys which are not trusted/certified, validation is skipped with that option.
--ignore-expiration is the new option for encryption to keys which are expired.

Encryption to disabled certificates shall not be allowed. I'll change this in the description, too

ebo renamed this task from Draft: Add a workflow to force encryption/signature with invalid/expired/disabled certificates to Draft: Add a workflow to force encryption/signature with invalid or expired certificates.Fri, Mar 27, 11:49 AM
ebo updated the task description. (Show Details)

Invalid certs (as stated in the status column in Kleopatra) are mainly S/MIME certs (e.g. with missing root cert, CRL check failed, etc). I haven't seen invalid pgp certs yet (might be e.g. very old ones with missing self signature).

The equivalent for invalid S/MIME certificates are not-certified *PGP certificates.
(Valid/invalid are not ideal as technical terms as they have a broad general meaning, too. I hope my usage here is correct ;-) It is what I gathered from an explanation given by Werner.)

Therefore in the *PGP case we need no changes for "invalid" certificates, we can already encrypt for them (the not-certified ones). For *PGP we only need to add an exception for expired ones.

Before making subtickets for each application: I wonder if it is not all Kleopatra anyway? Isn't the security approval dialog basically Kleopatra?