The Dialog to certify all keys should show a checksum over all the keys signed as I have a related subtask in mind for exchanging printed .kgrp files.

I think this (the checksum) belongs in the import dialog. Showing it when certifying a group is way too late.

Why? The idea is that someone might trick you by having printed out "Andre Heinecke <aheinecke@gnupg.com> 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1" Then adding the ID "Ingo ...." and sneakily adding that to the .krgp.

I don't see an attack earlier as the trick would be for someome to sign the Ingo Id.

I don't see how to calculate a checksum reliably if all you have is an arbitrarily sorted list of keys.

The checksum part for this was mentioned only in relation to T6470

So I want to have "Print Group" which will create two files. A .kgrp file with all the keys and so on. And a PDF listing all the user Ids and fingerprints and the checksum of the corresponding .kgrp file. So that later on no one can modify the .kgrp file.
When you have your Project Kick Off meeting you hand out the printed list of fingerprints and send around the .kgrp file. The document might even bevome part of the meeting protocol like "we have agreed on this list of certificates for our project communication" and then the users just need to verify that they are actually importing / signing the certificates contained in the .kgrp file that they previously agreed upon. And that is what this checksum is for.

Similarly in a Keysigning party we had this setup with a list of printed fingerprints and uids and then a slip with the checksum of that list.

The overarching goal of these three issues is to make it easier to use Kleopatra in an environment where you do not have anyone else to delegate ownertrust too and where you dont have a central directory like an AD.

That is basically the key signing party scheme we developed at the keyserver convention in Utrecht in 2000. Sometimes also known as Sassaman or over-the-lunch protocol. Gnupg used to come with a tool named ring-a-party which did the paperwork. However, experience has shown that it is too hard to explain and get right - even to key signing party geeks.

I understand all of this. I'm just pointing out that it's impossible to check the checksum of the file when you are certifying the imported group. The checksum needs to be checked when the file is imported because we need the file to calculate the checksum. Moreover, the checksum should be verified before the keys are actually imported because it may prove impossible to get rid of the imported keys after the import (because some keys could already have been in your keyring, so that you cannot simply delete all keys).

Additionally, in the case of a keysigning party you will only want to import the keys of those persons who did actually show up. Which means the group of imported keys will typically be smaller than the printed group of keys, hence any checksum over both sets of keys will never match regardless of some clever sorting which may work for identical sets of keys.

Wait, I just realize that one could prepare a group file with additional keys, omit those keys on the PDF, but still add the checksum of the file to the PDF. Maybe that's why you want to calculate a checksum over the actually imported group. I think this approach will not work in general. I already mentioned that you may not actually want to import all keys in the group. Moreover, keys which where already in your keyring before you imported the group (e.g. keys of your colleagues) may actually have more user IDs than listed on the PDF because you only want to give a single email address to the project partners. And there could be expired user IDs. There could even be user IDs which have expired between the preparation of the PDF and the time the group is actually imported. Some people will import this group weeks or even months after the kick off meeting.

I think this whole idea simply doesn't work. I think there's no way around a human ticking of each individual key on the PDF after cross-checking the fingerprints _and_ the user IDs.

I think that you both misunderstand my idea a bit. I would like to present it to you at some point over a Video Call or I have to write the proposal out in some longer form.

My use case is not really some kind of corporate keysigning party but rather an officially sanctioned list of the keys used for the communication in a Project. So that everything is nice and legal and traceable and responsibility can be shared etc.

On a related note in T6645 it was raised that it is currently impossible for the user to see if an exported group only contains local signatures which might decrease the value of the export and not be the intention of the person doing the export. Maybe we should combine a check for that with this feature so that you are asked when exporting a group if you really want to confirm all these identities.

result from meeting:

• add button "certify" in the "configure groups" window
• only the primary user ID should be exportably certified
• on export, export all IDs and inform the user if there were not certified IDs
• on exporting a not/partially certified group, inform the user and ask if they want to certify now

The certification of certificate groups (first two points of T6469#174361) is mostly done.

Defaulting to "exportable" is still missing. And the feedback on export (points 3 and 4 of T6469#174361) is still open.

Screenshots of the current state:

I had a look at the current state (VS-Desktop-3.2.0.0-beta229/231 from 2023-09-29):

When I want to certify a group where I am member myself, at first all the (primary) user-ids are marked and "Certify" is greyed out.

If I take away the check before my own certificate, I can certify. But we should not expect the user to know this.
It takes a long while for my own certificate to be deselected on it's own, I'm not sure it does ever if I do not trigger it by e.g. viewing the details of a certificate.

I have created T6766: Kleopatra: On export, inform user about uncertified user IDs for points 3 and 4 of T6469#174361.