GPG

User IDs

Each UID is tied directly to a primary key (n:1). This means that separate identity requires a separate primary key. Using multiple UIDs on the same primary key is only reasonable if you use all of them in the same capacity, or otherwise want to share subkeys between them. I can't really think of a scenario where this actually happens or would be necessary. Why separate UIDs if they would be used in the same capacity? And subkeys can be generated and revoked very easily, so sharing subkeys is imo completely unnecessary under any circumstance.

Here, I will assume only 1 UID will be assigned per primary key (1:1). Sticking to the 1 identity = 1 primary key rule also helps keep key management relatively simple.

Subkeys

Subkeys, like UIDs, are also each tied directly to a primary key (1:n). For this reason, I personally prefer to regard the subkeys as more like device IDs. For example, a subkey for my phone and another for my laptop, both tied to a primary key representing my work identity.

PGP keys have 4 functions:

Signing
Encrypting
Authenticating (not regularly used)
Certifying (internal use only)

Signing

Signing is used to prove that a given material is validated by you. It proves that the owner of the primary key has validated the signed content. Since the signature could have only been generated by your private key, others would be able to verify the signature using your public key.

Signing is a fungible function; the specific subkey used to sign isn't meaningful and can be used interchangeably. A new subkey for the same purpose should be generated for each device to avoid having copies across devices. When a device is no longer used, the subkey can simply be revoked.

Encrypting

Encrypting is used to conceal the content of a given material which can only be decrypted by the owner of the corresponding private key.

Encrypting is not a fungible function; the exact key used is critical. Often will be shared across multiple devices, and therefore should be treated sensitively, for example locking them with unique passwords.

Authenticating

Authenticating is used to simply prove that you are the owner of the primary key. It is a fungible function.

Certifying

The main role of the primary key, in some sense, can be said to certify the validity of its related subkeys and UIDs.

Certifying is not a fungible function.

Generating new keys

The default behavior of GnuPG generates a primary key that is capable of certifying as well as signing, and a subkey capable of encryption. However, you should never be signing anything with your primary key. Instead, you should simply create separate subkeys for signing purposes; that's what they're for.

Adding the line below in the configuration file would change the default behavior to generate a single primary key that is only capable of certification

default-new-key-algo ed25519/cert

Expiration and Revocation

An expired key should be considered outdated. It does not mean that the key is no longer valid; that is what revocation is for.

Expiration dates are not really for you; they are for everyone else with a copy of your key. It is a way to inform others that they should get a newer version. All public keys should have an expiration date, especially primary keys. Even if they are intended for indefinite use, they should be set to expire after a period of time. For example, setting them to expire two years in the future and updating them annually gives everyone else at least year before they need to check for updates. Private keys don't need to be renewed.

# open key editor
gpg --edit-key keyID

##### inside editor ######
#select key (N = index)
gpg > key N

#set new expiry
gpg > expire

# save
gpg > save

On the other hand, revocation means that key will not be used again thereafter. Importantly, key revocation includes a reason. Unless it is revoked due to compromise, they key should still be considered trustworthy. A signature with a key that is revoked due to no longer being used is still a valid signature.

Any key that is not intended for renewal should be revoked. If transitioning to a new key, revoke it and put the fingerprint (or the source) of the new key in the revocation comment. This way, when someone gets a copy of the old key, they know how to proceed.

# revoking a key
gpg --output revoke.asc --gen-revoke keyID

# importing revocation certificate into your keyring
gpg --import revoke.asc

# send the revoked key to the keyserver
gpg --keyserver keyserverURL --send-keys keyID

Setting preferred keyserver

Set it to a public URL. The URL does not have to necessarily be a keyserver; simply a statically hosted export of your public key will suffice. As long as the keyserver is active and up to date, anyone with an old copy of a key can trivially obtain the newest copy (automatically using --keyserver-options honor-keyserver-url).

GPG