Using signed files would have been my suggestion, too. For me I would say that "allowed to sign" depends on the ownertrust of the signature certificate. If the ownertrust of the certificate is Ultimate then you can accept the recipient list. Ultimate ownertrust is given for your own keys or for the ones marked with trusted-key in the GnuPG configuration.

But since we do not want to have any implicit behavior there that is unclear to the user it should be configurable anyhow to be:
a) A signature by an arbitrary list of keys
b) A signature from your own keys and keys marked as trusted-key (Wording would be something like, "your own keys and your organizations certifier keys" I am a bit unsure what we call a trusted-key otherwise)
c) Any fully valid signature

I am not sure I like every aspect of passtore.sh (e.g. the YAML configuration files and yet another group concept where we probably could reuse Kleopatra groups), but it's good to know that there is already a solution for this issue :)

Signing the .gpg-id files when creating/editing them sounds like something that we probably should do in any cases and is not really difficult to implement. We can later see which signature is considered trusted or not either with something simple like Andre suggested or something a bit more complex like passtore or similar.

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.

My idea for that were signed group files. Including at least a minimal version of the public keys with a file but as I remember the discussion @werner and @ikloecker were strongly against putting keys into such a file since this would be another place where keys would need to be updated etc. and only wanted to put the fingerprints in that file, leaving the key discovery to LDAP. And if I remember correctly the discussion drifted away from the re-encrypt usecase to a discussion about bulk certification and the exchange of such keylists. With leftover tasks from that idea / discussion were then T6469: Kleopatra: Certify a group and T6470: Kleopatra: Printable groups for group improvements. And T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients is just something in the backlog but not on the agenda. But as I see overlap here maybe we can change that and work on both these things.

As a format I would then still suggest to use the same as with key groups where we can sign the list of the fingerprints.

[KeyGroup-87ed2h3C]
Keys=A70B7ABDAC93ACFA8742E9EF43DE2327B7C859E0, F675E7BE0C8C9953192205CC4EBF03EA7AE167D1
Name=meal-planning
Sig=iHUEABYKAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCZrMiPwAKCRApeOnUDLq6XMmrAP4+88F3NrAEQibhkVsHWGRNY6xu3si9ZW/lp6DJLoQhAQD/T0BCByZjwnBQBIPg1ekW976RqGUpBzKq7IyT7vyXsQQ=

In this example i would define sig as a base64 encoded detached signature of the key=value pairs in the same ini group, sorted alphabetically. To leave it open what kind of meta data is signed there.

And it is optional if the actual keyblocks, like in a key group, follow or not. Such a list could be automatically cerated by kleopatra and embedded into an archive, of course with an option to turn this off, and then used if it is found when re-encrypting. And Gpgpass could use the same file for its information.