Subkeys
Modern OpenPGP keys are actually a set of keys. This set contains a primary key and (usually) several subkeys.
When generating a new key with sq key generate, sq will create 3 subkeys along with the primary key: Each of the subkeys are marked for their respective use (authentication, signing, encryption).
This set of subkeys is identified by it's primary key, so adding and removing them doesn't change the fingerprint. Certifications are made for the primary key as well - so modifying the subkeys doesn't affect them.
Subkeys are just like ordinary keys. What makes a key a subkey, is the existence of a subkey binding signature, which marks a specific key as subkey to a primary key.
Subkeys are different from primary key, as they do not contain user ids.
Primary keys and subkeys can be thought of as a tiny local personal PKIs, where the primary key is the CA, certifying the subkeys.
Scenarios
The reason for using different subkeys for different purposes is to separate the functionalities to achieve the greatest possible safety without restricting their usability. They can be treated and stored differently depending on their purpose and security needs.
Subkeys are key pairs, but associated with the primary key. For example, there is a difference between GnuPG and Sequoia PGP in how keys are structured by default when it is generated. GnuPG generates a signing and certification key as primary key and an encryption subkey in addition, whereas Sequoia PGP generates a primary key for certification and respectively subkeys for authentication, signing and encryption.
The primary key should be the most protected one and therefore stored offline where no one can have access to it. For this reasons the best practice would be not to publish the primary cert. Instead it makes sense only to publish certs of subkeys to avoid that other people use the cert of primary key. Again, this is not a security consideration, but if people use the primary certificate, it will become difficult to keep the primary key offline.
In this scenarios subkeys are the ones to use for frequent work. Then you just need to publish the certificates of the respective subkeys. It makes sense to rotate them more often by revoking them faster and let them expire earlier than the primary key. The primary key can be used to revoke a subkey if it's needed.
To prevent losing data if an encryption subkey gets lost, it's necessary to have a backup of it in a safe place.
In case of a signing key it is not as important or even not recommended to have a backup file. This is simply to minimize the risk of key theft by avoiding storing it in two different places. The functionality will not be limited, signatures made previously with that key still remain valid and for future signatures you can easily generate a new one using the primary key.
Just a site note, in some countries there is even more a need to separate keys for encryption and signing in terms of key disclosure laws. For example in the UK and in France it can be construed as a crime not to decrypt and/or hand out a decryption key to law enforcement agencies if recommended even without a court order. In this cases the rest of the key material should remain safe.
- How to use subkeys, especially how to use them when the primary key is offlined.
sq key subkey export... - https://openpgp.dev/book/certificates.html#component-keys
- different subkeys for different devices