Last December we started to provide GnuPG as Debian style packages with an additional external repository on software.shimps.net. The trust anchor is the repository signing key which must be deployed with
cd /etc/apt/keyrings wget https://software.shimps.net/keys/gnupg/shimps-signing-2024.gpg
I published the fingerprint in a signed email on the gnupg-users mailing list. This way the trust anchor is shifted to the key I use to sign emails on that list. This key is available via WKD (as well as the signing keys are).
The recommended package shimps-keyring is intended to simplify future key updates. Meanwhile there is a new signing key prepared, which is not used for the repository (or even in the keyring package) yet, but ATM intended to sign Git commits, e.g. to Codeberg diy-gnupg. It needs to be imported into the user's keyring if you want to verify the commits. Quick and dirty import:
cd /etc/apt/keyrings wget https://software.shimps.net/keys/gnupg/shimps-signing-2025.gpg gpg --import /etc/apt/keyrings/shimps-signing-2025.gpg
Since this key will be shipped with the keyring package eventually, there is no need to deploy it below /etc/apt and you might want to import it via WKD:
$ gpg -v --auto-key-locate clear,wkd,nodefault --locate-keys signing.2025@shimps.net gpg: using pgp trust model gpg: pub ed25519/52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net> gpg: key 52CAACDAA420187C: "Frank Guthausen (signing 2025) <signing.2025@shimps.net>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint E614303270D94B76EF285FFA52CAACDAA420187C gpg: automatically retrieved 'signing.2025@shimps.net' via WKD pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614303270D94B76EF285FFA52CAACDAA420187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08]
Keep the trust anchor in mind. If you get the key from the website (download or WKD) you (and I) need to trust the provider to host and ship the correct key and you need to trust https encryption with an Let's Encrypt certificate.
The signing key from December 2024 is RSA 3072.
$ gpg -k signing.2024@shimps.net pub rsa3072 2024-12-17 [SC] [expires: 2026-12-17] 2BBD6FF068FEF7905A531348ECB53FD18ACCCF7C uid [ultimate] SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub rsa3072 2024-12-17 [E] [expires: 2026-12-17]
or
$ gpg --fingerprint --fingerprint --with-sig-list signing.2024@shimps.net pub rsa3072 2024-12-17 [SC] [expires: 2026-12-17] 2BBD 6FF0 68FE F790 5A53 1348 ECB5 3FD1 8ACC CF7C uid [ultimate] SHIMPS Signing Key 2024 <signing.2024@shimps.net> sig 3 ECB53FD18ACCCF7C 2024-12-17 SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub rsa3072 2024-12-17 [E] [expires: 2026-12-17] B3E8 C9E5 48CC CDC4 1C70 0650 4D19 8A44 C9AE 8FA6 sig ECB53FD18ACCCF7C 2024-12-17 SHIMPS Signing Key 2024 <signing.2024@shimps.net>
The signing key from April 2025 is an ECC key with curve ed25519. It is signed with the 2024 signing key to establish a chain of trust.
$ gpg -k signing.2025@shimps.net pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614303270D94B76EF285FFA52CAACDAA420187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08]
or
$ gpg --fingerprint --fingerprint --with-sig-list signing.2025@shimps.net pub ed25519 2025-04-09 [SC] [expires: 2028-04-08] E614 3032 70D9 4B76 EF28 5FFA 52CA ACDA A420 187C uid [ultimate] Frank Guthausen (signing 2025) <signing.2025@shimps.net> sig 3 52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net> sig ECB53FD18ACCCF7C 2025-04-09 SHIMPS Signing Key 2024 <signing.2024@shimps.net> sub cv25519 2025-04-09 [E] [expires: 2028-04-08] 45F2 E58A 454A 8FFA DE16 11EE A3F2 65E6 7497 B0AB sig 52CAACDAA420187C 2025-04-09 Frank Guthausen (signing 2025) <signing.2025@shimps.net>
In principle it would be possible to work with one main key and several subkeys for different email addresses and purposes. At the end a choice has to be made. Dealing with only one key might be more convenient and less work here and there, but you cannot seperate roles on a fine grained level. Thoughts about data protection might occur, or it can become cumbersome to deal with subkeys. And finally it is a question of workflow, taste and/or personal preferences. There is no one size fits all solution.