Page MenuHome GnuPG

Kleopatra: Certify a group
Closed, ResolvedPublic

Description

I have two usecases in mind for this. The most important one is that you have the situation that the Ministry sends you (ideally) a signed .kgrp file and says "Hey these are the Keys for Project XY". Even if they are already signed by "sec-com-mngr-xy@ministry.gov" you don't want to mark "sec-com-mngr-xy" as trusted for all your employees.

So you as the trusted key of your organization or team can sign this keygroup with exportable signatures and hand it out to your team.

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.

Update (2023-09-28): We have changed the scope of this task a bit some time ago. In particular, the idea to show some checksum for a group was removed from this task. See T6469#174361.

Revisions and Commits

rLIBKLEO Libkleo
rKLEOPATRA Kleopatra

Event Timeline

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
ebo raised the priority of this task from Wishlist to Normal.Aug 18 2023, 12:17 PM
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.

ikloecker changed the task status from Open to Testing.Oct 16 2023, 12:09 PM

The issue mentioned in T6469#176392 is fixed.

Moreover, the certification process is now aborted immediately when the user entered a wrong password for the first certification (for subsequent certifications the cached password is used by default) or when the pinentry timed out. In these cases, there user may want to restart the certification instead of ending up with a partially certified group.

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 31 2023, 2:13 PM
ebo claimed this task.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

It works for the standard use case where we have keys with one user ID.

I found the question window "Save changes?" very annoying, which usually pops up directly after certifying a group you have added a user to directly before certifying.

I think that "save" is the only sensible option here, therefore it should be done automatically. But this is probably covered by T6662.

Some things which might be unexpected, but should not happen usually or should be no problem:

  • If you're not sure if you already certified the group and click on certify again, you will add another certification without noticing it
  • In case of certificates with multiple UIDs it is confusing that they are labeled "not certified" although the primary UID is, and therefore an export of the group without warning is possible
  • You can export a group without warning which consists only of different keys for which you have the secret key. But the aim of the warning before the group export is that all the certificates should be signed by one and the same key, not by different ones. So the warning only works as intended for groups of public keys.
ebo moved this task from Backlog to vsd-3.2.0 on the vsd32 board.
ebo edited projects, added vsd32 (vsd-3.2.0); removed vsd32.