Thanks for the comment response, that helped a little bit.
These are general recommendations, YMMV and you can always tweak them to your own needs. This is just a good place to start and things to keep in mind, but proper security posture is an individual endeavor, not a one-for-all thing.
First off, don't sign your new key with your old one. If you haven't used the old key before then it doesn't have an existing chain of trust, so using it to sign something isn't adding much (if any) weight to the identity assertion. And once you revoke the old key (our next step) then it will add zero weight to any claim made. This is only useful if your old key has been previously used as it helps assure other folks that the new key isn't a scam (they trusted the old key, which is telling them to trust [signing] the new one)
Note: whenever I say "key" I mean the same as what you seem to be calling "main key". I will specify "sub-key" when talking about a use-specific descendant of the "key".
Secondly, revoke your old key -- make sure to put the reasons in the revocation (reason is either "no longer used" or "superseded"), and put in a description that includes your new key ID "Key has been replaced for logistic reasons, new KeyID is 12BC-A29D". Once you have the revocation certificate created, publish it to the public key servers (really, just send it to MIT, it'll make it from there). This takes care of turning off the old key; you've revoked it and listed it as unused in the public servers (with a hint and how to find/validate your new key). At this point you can totally forget about your old key.
Always Remember :: When removing keys from public key servers you MUST issue a revocation certificate and submit that to the server. Even if some servers include a "delete this key" field, they're lying at it won't fully delete it. The only way to truly cancel a previously published key is to issue a revoke.
Now, on to your new key.
You've got a decent start here. The normal recommendations are these:
- Make your key time-limited.
Normally this results in people making 1-year (I use 13 months) expiration dates on their keys. Then they will perform maintenance yearly, during which they'll extend the expiration and send the updated key to the public servers. This provides protection against lost/unused keys, they'll automatically expire unless you take a regular action to refresh them.
- Make a revocation certificate up front
This is in case of loss. The general recommendation is to have either a "no reason" or "key compromised" revocation certificate made just after you make the new key (before you submit it to public servers even). Then to print this certificate (I highly recommend an OCR font) and throw it in your physical safe keeping location (a safe at home, a bank deposit box, where ever you'd keep important & hard-to replace documents like original birth certificates or original social security cards and passports). Should something happen that causes you to lose control of the key, you will still have a way of revoking it; that makes it a really good just in case item.
- Don't worry yourself about the sub-keys
I'm not saying don't use sub-keys. I'm just saying that you are using a well made PGP implementation (I have GPG on all my machines, regardless of OS) that handles all of that for you. You raise several points regarding Sub-Key IDs or sub-key attestation and management, and while those are things that we have to worry about on the design and implementation side they aren't things an end-user need to fret over. The GPG software has created a Key Pair for you, and (at your instruction) created a set of managed sub-keys for specific purposes. When you use GPG to sign something, it will automatically use the proper sub-key; same for encryption & authentication (if you create an auth key and have something that'll use it). If you want to dive into how PGP works, that is a whole deeper pond, but for just using it all you need to worry about is "your key" (what you seem to be referring to as the master) in GPG -- the software will handle the rest from there.
- Your key is you
That PGP key is now leveraged as an identity source. People can verify something was done by you simply by checking a signature. Don't muddy up the waters by creating entirely separate keys. If you need, you can add more User-IDs to the existing key (useful if you get a new email address, or if you need to attest to a new persona you carry). If you want to sign something, use the signing sub-key of your key; that's the whole reason for sub keys. If you ever get something that was handled by a PGP key with the master ID of 6742F54F27B19AC2 then you know it was from me. The key is you, don't fragment your identity into multiple keys, but also protect your key just as surly as you'd protect your birth certificate and passport. Your protection can vary from adding a passcode to the PGP key (GPG should have prompted you to create one, but you could have chosen not to) up to offloading the private-key component onto a smartcard (I do this, with a YubiKey) to give you that multi-factor and physical possession safety net; this is very much one of the "what is best for you personally" items.
TLDR -- Don't sign the new key with the old one. Issue a revocation certificate for the old key and submit it to the public servers. Make sure your new key has an expiration date, you can make it not-to-far-out and just extend it regularly. Don't worry about manually managing which sub-key to use. Don't create 2nd (or 3rd) keys for different purposes. Do protect your key as if it was enough information to steal your identity (because it is).
