Page MenuHome GnuPG

Kleopatra: Better way to show expired subkeys
Open, NormalPublic


Kleopatra should also check the subkey's expiration status when deciding whether an OpenPGP key is displayed as expired.

Kleopatra checks only the primary key's expiration date. Users are often surprised that a key is not shown as expired but the encryption fails anyway due to an expired subkey. The key details windows shows the expiration date of the subkey but most users don't known about this.

Event Timeline

werner triaged this task as Normal priority.Jul 27 2022, 3:22 PM
werner created this task.

This is related to T5950: Allow viewing expired certificates more easily where a user was wondering why some key wasn't offered as encryption key. It turned out that the encryption subkey was expired.

The question is how to show that a valid certificate (i.e. the primary key is valid) doesn't have a valid encryption (sub)key resp. only has expired encryption (sub)keys. One solution coming to my mind would be to show color-coded usage icons, e.g. a green signing icon and a red encryption icon if the certificate has a valid signing (sub)key but only invalid encryption (sub)keys. The problem is that this compact visual solution isn't accessible (e.g. in high-contrast mode where we explicitly turn off all color). This could be solved by additionally crossing out the icons for invalid usage.

I'll add Eva and Andre for brain storming ideas.

ikloecker renamed this task from Better way to show expired subkeys in Kleopatra to Kleopatra: Better way to show expired subkeys.Jul 27 2022, 4:48 PM

Another point where this is very problematic are S/MIME certificates for signing and encryption. While the certificate line edit and the certificate combo box filter the usage, Groups are problematic. If you want to create an encryption group and include one "signing only" certificate the whole group is no longer visible for example in Outlook when encrypting. Both me and Eva thought that S/MIME Groups did not work at all in Outlook because of this.

The first step would be in my opinion to add another optional column to the certificate tables. "Usage" which would contain: "sign, encr, cert" although I wonder how to shorten "encr" in German. "Versch." probably. That would at lease give the option to view the usage in the group creation / edit dialog.

We could use single letters or icons (with proper tool tip and accessible name). I'm not sure mentioning the cert usage is that useful.

Should the effective usage or the key capabilities be shown, i.e. what to show for an OpenPGP key with expired encryption subkey. Above I proposed a crossed-out 'E' (or equivalent) in this case. But what about 'S' and 'C'? An expired signing key cannot be used for signing, but it's still valid for verifying old signed data. On the other hand, an expired certification key renders all existing certifications invalid. So, that's easy again.

Another idea (based on above ideas): We add an optional column named "Valid For" and only list the usages that are currently possible. If the encryption subkey is expired, then the key will probably only be valid for signing and certifying. This should be easier to understand than my fancy color coding idea while still giving the user a hint what a certain certificate can be used for. I'd still abbreviate the usage to a single letter in English. Translators could still use more letters if a single letter would be ambiguous.

This idea "hides" the information that a key has an invalid encryption subkey, but an invalid encryption subkey is of no use and thus not much better than no encryption subkey at all.