Page MenuHome GnuPG

Kleopatra: Add automatic offer of revocation certificate export to the revocation process
Testing, NormalPublic

Description

We could improve UX for revocation by making the revocation related additional tasks more self-explanatory.

After optionally (if a keyserver is configured) offer to upload the revocation, we should then offer to export the certificate. In that dialog window we should explain very shortly what is to be done. like e.g. "Do you want to export the certificate? The exported certificate can then be send to communication partners to inform them about the revocation."

We could possibly only offer the export if no keyserver is configured. Or do it in all cases; maybe a company only uses an LDAP internally and external people get send a file.

See also T7076: Kleopatra: Improvements in the "Revoke Key" window

Details

External Link
https://invent.kde.org/pim/kleopatra/-/merge_requests/172
Version
gpg4win 4.3.1 / vsd 3.2.1

Event Timeline

TobiasFella moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

I just want to point out that we have explicitly decided to remove confronting the user with five different "What next" options in the certificate creation workflow. One reason is that the choice overwhelms the users because some think they need to do everything. Another reason is that many options were completely wrong for some of our customers. Such workflows are much better documented in company-specific SOPs (standard operation procedures).

I think it's ironic (and wrong) that we now re-introduce confronting the user with exactly the same "helpful suggestions" (publish, export) in another workflow.

Publishing should happen either automatically or via the standard workflow. Same for export, e.g. Kleopatra could automatically export the revoked certificate to a file and tell the user the location.

Revocations are an exceptional task and rarely needed. In this case ("help, help , my key is compromised, what shall I do now?") an extra dialog to help the user is imho appropriate. This different for the key generation process, becuase this needs to be done by every user at least once and thus should be UI-wise as simple as possible.

That said I think we should then strive to use only one "next" window.

Edit: what I deleted was wrong, we do not offer a keyserver upload currently.

Alexander suggested that we could avoid another window by putting check boxes in the revocation window for automatically uploading to the configured keyserver and creating a public key export with the revocation. That could then be configurable via the registry on windows, so that companies could adapt that according to their SOP.

I like the suggestion to add a checkbox for the upload. That's also in line with certification which is very similar to revocation.

Regarding the public key export I still think that we should just do it and tell the user the location of the file (I think the Documents folder is suitable) in the success message. It's one decision less for the user to make. In any case we should perform a minimal export.

I'd propose that we could:

  • Always export the certificate and tell the user in the success dialog
  • Have an extra button in the success dialog allowing the user to upload the certificate.

That way, we don't have any extra dialogs. The user might still click through all dialogs without reading anything, but I'm not sure how we could prevent that

We decided to go with Tobias' proposal.

The export should be to a standard (not hidden) location, like $XDG_DATA_HOME. Does that exist on Windows, too?

In case of LDAP keyserver, upload should be the preselected default

Was mentioned before, but not written here:

The reasons should be in a fold-out section (like the Advanced choices elsewhere) with the always readable title "Reason for revocation (optional)". This way, the window will be less of a wall of text and concentrate on the important parts.

ebo triaged this task as Normal priority.May 3 2024, 9:05 AM
ebo set External Link to https://invent.kde.org/pim/kleopatra/-/merge_requests/172.May 3 2024, 12:59 PM
ikloecker changed the task status from Open to Testing.Jun 7 2024, 2:36 PM
ikloecker moved this task from Backlog to WiP on the vsd33 board.

backported

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 1 2024, 3:55 PM