I want to create a new GPG key with a longer key size.
What are the best ways to replace the key ?
My current key is associated with a lot of stuff like GitHub etc.
Should I revoke my old key and sign the new one with the old ?
So what's the best way to do it.
On your question
I see by inspection of your keys that are posted on public key servers, that you have already posted your revocation certificate for your old key. The revocation certificate includes the fingerprint of the new key. So, your method seems acceptable, and probably better than many other attempts at the key rollover process.
Personal key management is mostly an opinion based exercise. Recommendations abound, and some seem better than others. Cross-signing the public keys is probably a better method without resorting to a third party identity tracking service such as keybase.io
It's usually a good idea to revoke keys only when absolutely necessary, such as a lost private key or a compromised key. Modern
gpg implementations create a revocation certificate as part of the key generation process. On my Debian Buster system, those certificates are automatically stored in
~/.gnupg/openpgp-revocs.d So, as long as one keeps the revocation certificate, one can revoke a posted public key at will regardless of whether or not one remembers the passphrase or has the private key.
Expiring old keys rather than revoking them is probably a better method, because the expiration date on a pgp key can easily be changed at will and posted to a public key server without permanent repercussions.
Lastly, always keep the old keys. Don't discard the private keys thinking that you won't need them anymore. All old messages encrypted with old public keys will not be accessible without the old private keys.
On public key servers
Anyone can post any public key to a public key server. So, it's not a good idea to blindly trust keys discovered on public key servers. The key servers are also littered with old, compromised, expired, and revoked keys. It's very difficult to figure out or verify that a given key on a key server is the correct and current key for communication with the identity information listed on the key.
The original idea was that people with keys would get together in person-to-person meet-ups called key signing parties to sign each other's keys and build a web of trust. However, key signing parties are not that common and most keys I've come across are simply self-signed with zero other signatures. So, in general practice, the web of trust doesn't work out so well to determine which key belongs to which identity and which key is the most current key.
These problems are a few which keybase.io has been trying to solve. Keybase replaces the person-to-person web of trust with verified identity tracking across third party web services such as Github. However, effective use of keybase requires that one maintain third party accounts on web services that track you. So, online anonymity takes quite a huge hit with keybase use. Some may say it's an acceptable trade off, and some may not wish to accept that trade off.