From my understanding of public key infrastructures (PKI) a "root certificate authority" must be self-signed and capable of signing other certificates below itself. In a similar capacity, the offline master key described would also need these same privileges.
- Certify (C) - the primary key "master key" MUST be a key capable of certification (so for subkey sets).
- Signing (S) - will be required for the "master key" to encrypt data (or keys) with its private key.
From what I have derived about CS it will be required for the master key to operate in a capacity of an offline master key (PKI). However, further reading led me to a GnuPG article Signing Subkey Cross-Certification. Which outlines the "master key" does not self-sign itself (like our PKI), which creates a weakness "the signing subkey does not sign the primary to show that it is owned by the primary. This allows an attacker to take a signing subkey and attach it to their own key". This is further discussed "GPG why is my trusted key not certified with a trusted signature?"
Also see, "Which actions does the GnuPG certify capability permit"
and "Anatomy of a GPG key"
Which outlines: "Certification vs. signing - ‘Signing’ is an action against arbitrary data. ‘Certification’ is the signing of another key. Ironically, the act of certifying a key is universally called “key signing”. Just embrace the contradiction."
Hence, I would advise CS for your usage.