GPG subkey layout. Separate keys for C, S and E?

Question

I've been reading up a lot on GPG recently. This page describes how to setup so-called "laptop keys". The idea being that if you lose your laptop, or have it stolen, your primary certification key, which you locked away at home, is still under your control. You are then free to revoke and reissue your subkeys. Further, you do not have to re-establish trust with those whose key you have signed (please correct me if I am wrong).

In the blog post linked above he sets up the keys like this:

pub  4096R/488BA441  created: 2013-03-13  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
This key was revoked on 2013-03-13 by RSA key 488BA441 Bilbo Baggins    
sub  4096R/69B0EA85  created: 2013-03-13  expires: never       usage: E
This key was revoked on 2013-03-13 by RSA key 488BA441 Bilbo Baggins    
sub  4096R/C24C2CDA  created: 2013-03-13  expires: never       usage: S   
[ultimate] (1). Bilbo Baggins 
[ultimate] (2)  [jpeg image of size 5324]

I was wondering if there is any profound reason as to why the primary key has the signing S flag set. I had a play with GPG and found that by using expert options I could make a key (for example) like this:

pub  4096R/488BA441  created: 2013-03-13  expires: never       usage: C  
                     trust: ultimate      validity: ultimate
This key was revoked on 2013-03-13 by RSA key 488BA441 Bilbo Baggins    
sub  4096R/69B0EA85  created: 2013-03-13  expires: never       usage: E
This key was revoked on 2013-03-13 by RSA key 488BA441 Bilbo Baggins    
sub  4096R/C24C2CDA  created: 2013-03-13  expires: never       usage: S   
[ultimate] (1). Bilbo Baggins 
[ultimate] (2)  [jpeg image of size 5324]

Each key is now for a single purpose. Is this a good way to lay out your key pairs for laptop keys? If not, why not?

Answer 1

The distinction in signing and encryption keys is mostly a necessity for algorithms not capable of doing both: for example, when using DSA for signature, you need another ElGamal encryption subkey. Thus, by default signing and encryption have been split into separate tasks. Certifications are technically also signatures, thus those two capabilities are combined by default.

For having an offline key (and generally being able to revoke single keys, for example after trouble like Debian had with DSA and being able to calculate back the private key based on many signatures), it seems reasonable to completely split up capabilities, removing the signature capability from the primary key and creating an additional signing key.

TL;DR: Go for it, there are no disadvantages if you want to limit the primary key's use to certifications and key management anyway.