Since most key types can be used for multiple purposes, namely certification, authentication, encryption and signatures, one could simply use one key for everything - which is a bad idea, as elaborated e.g. by Thomas Pornin. So one should use different key pairs for different purposes, with different backup methods (decryption should remain possible "forever", while signature keys can "simply" be replaced) and securing. But I haven't managed to find a one-in-all write up of best practice summarizing answers to the following questions:


What type of key should be used for which purpose (RSA, DSA, ... how many bits, when should they expire etc)?
Should all keys be (separate?) subkeys of the certification master key or be individual master keys signed by the former one? I found some non-trivial guides on how to remove the secret master key from your day-to-day used subkeys, but is the trouble involved really worth having a shorter chain-of-trust to these keys compared to an entirely separate certification key?
How important is it actually to keep the certification key offline when one uses a) a "really" strong passphrase or b) a hardware device like an OpenPGP card?


About Using Subkeys

Use one primary key for each identity you need, otherwise, use subkeys.

Examples for using multiple primary keys:


You don't want to mix up your private and professional keys
You need some key not connected with your "real life" identity, eg. when prosecuted by the authorities


Examples for using subkeys:


You want to use multiple keys for multiple devices (so you won't have to revoke your computer's key if you lose your mobile)
You want to switch keys regularly (eg., every some years) without losing your reputation in the Web of Trust


I recently posted about How many OpenPGP keys to make in another answer.

About Key Sizes

The GnuPG developers recommend using 2k RSA keys for both encryption and signing. This will be definitely fine for currently used subkeys.

As your primary key will not be used for anything but keysigning and validating signatures (and revocation of course), it is seen as good practice to have a quite huge key here, while using smaller sizes (huge enough for time you will need them) for subkeys (which will speed up calculations and reduce file sizes).

I had a more detailed answer facing RSA with DSA/Elgamal for another question at Superuser, go there for reading further.

Key Expiration

There are two ways a private key could get compromised:


Somebody is able to steal it from you
Somebody is able to recalculate it from your public key


First is a matter of your computer's security (and how you use your key, read below), second is a matter of time. Today (and probably the next few years), RSA 2k keys will be totally fine. But computing power rises dramatically, so an attacker needs less CPU cores/graphic cards/computers/power plants to recalculate your private key. Also, glitches could be found in the used algorithms, leading to much less computing power needed. Quantum computers could speed up things even more.

A key expiration date will limit the validity of your key to a given time you expect it to be secure. Any attacker cracking it afterwards will only be able to read encrypted data send to you, but nobody will use it any more; if an attacker gets hold of your key and you stay unnoticed, at least it will stop him from having use from it after a given time.

Expiring your primary key will let you lose all your Web of Trust reputation, but at least invalidates your key after a given time if you lose access (what should never ever happen, read on at the end of my answer).

Storing your Primary Key Offline

Your primary key is the most crucial one. All trust - both incoming and outgoing - is connected with this. If somebody gets access to it, he's able to:


Create new keys using your name (and GnuPG always uses your newest subkey by default!)
Revoking subkeys and primary keys
Issuing trust to other keys, which is the worst thing to happen: An attacker could create a new key, giving it trust from your old one and then revoke your old key, leaving you without any access to your "moved" identity - he's literally overtaking your identity.



  How important is it actually to keep the certification key offline when one uses a) a "really" strong passphrase [...]?


Your computer always could be hacked or infected by some malware downloading your keys and installing a key logger to fetch your password (and this is not a matter of which operating system you use, all of them include severe security holes nobody knows about at this time).

Keeping your primary (private) key offline is a good choice preventing these problems. It includes some hassles, but reduces risks as stated above.

Highest security would of course mean to use a separate, offline computer (hardware, no virtual machine!) to do all the key management using your primary key and only transferring OpenPGP data (foreign keys and signatures you issued) using some thumb drive.


  b) a hardware device like an OpenPGP card?


OpenPGP smart cards are somewhere in between storing it offline on a thumbdrive, but attaching it to your computer for signing and using another offline computer dedicated to this purpose. Your private key will never leave the smart card (except for backup purpose) which requires an "admin PIN", all signing and even key creation will happen inside the card. "Using" your key (encryption, signing, giving trust) will only require a "user PIN", so even if you connect the card to a "harmed" computer, the attacker will not be able to completely overtake your ID.

You can store your public key wherever you want, for having real use of OpenPGP, you even should send it (and your other public keys) to the keyservers.



And do not forget to create and print a revocation certificate of your primary key. Losing your private key not having this certificate means there is a key you cannot access any more lingering on the keyservers and you can't do anything about it.

Print it, possibly several times, and put it to places you trust. Your parents, some bank deposit box, ... - if this certificate leaks, worst thing to happen is losing your Web of Trust.
