I want to some guidance.
So let’s say you created a PGP key & then proceeded to create 2 subkeys. Is it possible to just export the particular subkeys only. (let’s say one for encryption & the other for signing) for OTHERS to import into their keyring for authentication & encryption ?
So let’s say you created a PGP key & then proceeded to create 2 subkeys. Is it possible to just export the particular subkeys only. (let’s say one for encryption & the other for signing) for OTHERS to import into their keyring for authentication & encryption ?
For the private key, yes. First identify the subkey ID:
gpg --keyid=format=long -K sec ed25519/5810B9EFF21686DE 2026-01-23 [SC] [expires: 2029-01-22] C9E33D15E55A3834EE17A9755810B9EFF21686DE uid [ultimate] alice <alice@localhost> ssb cv25519/F1806CEA56544D8D 2026-01-23 [E] [expires: 2029-01-22]Then export it (note the
!):gpg --export-secret-subkeys -a 'F1806CEA56544D8D!'If you want the pubkey subkey only: What’s your use-case for sharing a certified key without the certificate chain? There are reasons why exporting just the public subkey isn’t really a supported feature (outside of some ugly keyring surgery). If you want unsigned “naked” keys wouldn’t it make sense to not use subkeys at all to begin with? Or more practically, generate separate root keys with matching user/expiry but each with different set of subkeys present (like the example above with only
E) ?Let’s say I had a primary key that has a validity of 1 year & I didn’t want to share that & instead sign messages with my sub-keys for let’s say 4 months & use different sets of Subkeys with a validity of 4 months.
What purpose does (certifying with) the primary key serve there if you don’t disclose it prior to rotation? What do you gain by not disclosing it when its only used in this context? It may be you haven’t thought it through fully but otherwise sounds like you can get what you want by separate primary keys which you then manually
--sign-keybetween on demand.The thing is with each new primary-keys you have build up trust, but subkeys are associated.
It’s a covenience thing
The trust comes from the association. You can’t remove (or keep private) the association and expect to not have to separately rebuild the trust as a consequence. That what you are trying to do is made is inconvenient in GPG is quite intentional I believe. Or maybe I misunderstand your motivations, it’s a bit ambiguous and you leave a lot open for interpretation.
I just want to know if it can be done or not, if it cannot be done, then why ? If it can then how ?
Because it’s not something people commonly do. Because the GPG authors wanted to design for and encourage what they consider appropriate use and discourage and make difficult (but not impossible) what they consider inappropriate use. Removing a footgun for people not fully understanding the trust model of PGP or just slipping up doing that and then ending up in situations they didn’t account for. In general I could have a lot of criticism of the UI/UX of GPG but in this case I can see where they’re coming from and find this thread supporting it as working as intended so far.
That you need to have deep knowledge of obscure GPG internals to pull this off is by design. It’s not considered part of intended use. Similar thinking to why in Chromium you don’t have a button to bypass HSTS validation error but need to type in the cheat code “thisisunsafe”. It nudges users to stop and think more consciously about what’s going on.
Understood. Thanks for the help, I really appreciate it👌
