Keypair generation not following best practice

[duxsco]

Your script creates a keypair which doesn't follow best practice:

pub   rsa3072 2022-11-18 [SCEA] [expires: 2024-11-17]
      853CD87C75BB8597EE443A1763A85AA18D2BCF61
uid           [ultimate] first last (key of first last) <[email protected]>
sub   rsa3072 2022-11-18 [SEA] [expires: 2024-11-17]

This is how a rsa3072 based key should look like (IMO):

pub   rsa3072 2022-11-18 [C] [expires: 2023-01-01]
      42D60F0629CDEF77425A2BE347603971D8A86E34
uid           [ultimate] first last (key of first last) <[email protected]>
sub   rsa3072 2022-11-18 [S] [expires: 2023-01-01]
sub   rsa3072 2022-11-18 [E] [expires: 2023-01-01]
sub   rsa3072 2022-11-18 [A] [expires: 2023-01-01]

In general, I recommend Curve25519 over all other algorithms if hardware limitations don't speak against it.

I have this scripted here:
https://github.com/duxsco/gpg-smartcard#create-a-gnupg-keypair

FYI:
https://dev.gnupg.org/T4514

[shombando]

Hi @duxsco thanks for improving best practices, I see the open feature request you linked on gnupg dev list and thanks for linking your script. Could you please provide some links on where this best practice is discussed/described? I'd like to link to that in the documentation and allow the user to make informed decisions.

[duxsco]

fyi, I have updated my section on GnuPG key generation. I plan to add brainpool and secp for completeness sake.

There is a reason for the concept of "capabilities" to exists and having primary-/subkeys with distinct and unique capabilities on each one follows common sense. That's how smartcards were designed as well as tokens such as the Nitrokey and Yubikey. They have 3 slots, one for "sign", one for "encrypt" and one for "auth", where the subkeys with these distinct capabilities get copied.

I don't have a link at hand. But, you should be able to find info on this topic pretty quick.

Here are advantages I see in real-life:

• The "auth" subkey isn't needed by others. It's only needed by the keypair owner to, for example, ssh on a server. Thus, it's good to keep it separate and not publish it with the other keys.
• If you decide to rotate subkeys and let the old ones expire, the expired "encrypt" subkey becomes obsolete. The expired "sign" subkey, however, should be kept around for others to be able to check your old signatures. Thus, you only need to publish the expired "sign" subkey. To be able to do that, the "sign" subkey must be distinct.
• You decide (for reasons) to rotate your (offline and thus securely stored) "auth" subkey every 5 years, your "sign" subkey every 3 years and your "encrypt" subkey every year.
• The primary key with "cert" capability is able to create new subkeys. It's not required for daily work. Therefore, it should be and can be kept in a secure location, e.g. on an air-gapped laptop.

[duxsco]

I use self-hosted WKD. So, I am completely free to "update" my pubkey. I don't know whether you can remove obsolete keys, e.g. an expired "auth" subkey, from e.g. keys.openpgp.org.

[duxsco]

I think you need the "cert" capability to create notations. But, how often are you gonna do that? I for once will create my handful notations a single time on my air-gapped laptop where the "full" keypair is stored (primary key with "cert" capability). But, only after this issue gets solved 😉
https://codeberg.org/keyoxide/keyoxide-web/issues/142

[duxsco]

For completeness sake, why I use self-hosted WKD:
https://fosstodon.org/@chelnak/109319459016800183

I noticed some other deficits of my key generation script. It's been a while since I touched it... I notify you after applying the fixes.

[duxsco]

I updated the section and applied recommended settings for keypair generation, a subset of my gpg.conf.

[shombando]

@duxsco I've set a new release with updated documentation around privacy and security and pointed people to the discussion on this issue thread. Thanks for taking the time to help improve awareness and sharing your own scripts as a reference.
https://github.com/shombando/keyoxidizer/releases/tag/v.0.2.4

[shombando]

Further comments on best practices from community: https://codeine.world/objects/21174ace-14ef-4754-b69c-751a1b921758

[shombando]

Switched to using ed25519 curve. Thanks for all the help and education here.