Understanding Key Usage in Root Certificates
The Key Usage extension, when present, contains the exhaustive list of usage types that are allowed with the public key. When a system processes a certificate, it does so for a given purpose, and thus must verify that the Key Usage extension, if present, allows that usage. Specifically, when a system analyses a CA certificate and wants to use its public key in order to verify the signature over another certificate (that the CA purportedly issued), then this is a ‘certificate sign’ usage; so if the CA certificate contains a Key Usage extension, then the system will require that the extension contains the keyCertSign flag.
Nothing prevents a Key Usage extension from containing other flags as well! The verification is positive-only: systems check whether the flag they want is indeed there; they never check that a flag they don’t want is absent.
Since a CA is supposed to issue certificate and CRL, it should have, on a general basis, the keyCertSign and cRLSign flags. These two flags are sufficient. If the CA does not intend to sign its own CRL, then it may omit the cRLSign flag; however, a CA without the keyCertSign flag makes little sense. One may want to include other flags if the CA key is meant to do other things as well (although this is not recommended: a general rule is that a cryptographic key should be used for one thing only). One may imagine, for instance, doing some key escrowing by encrypting the private key of issued certificates with the CA’s public key, so that the CA may recover the private key under certain conditions (this is not a bad idea when the user’s key is meant for data encryption).
Therefore, nothing prevents the Key Usage extension from containing other flags. Alternatively, the Key Usage extension may be missing altogether; this is equivalent to ‘all usages allowed’.
Microsoft’s ‘Off-line CRL signing’ is just another name for ‘CRL signing’. Indeed, the page you link to says this:
To apply this key usage if a CA certificate is requested, type the following at a command prompt, and then press ENTER:
echo 03 02 01 06>File_Name.txt
We here recognize the ASN.1/DER encoding of a BIT STRING of length 7 bits, with bits 5 and 6 set, and bits 0 to 4 cleared; this is the encoding of a Key Usage extension with flags keyCertSign and cRLSign. Though they use their own terminology, Microsoft actually conforms to the standard for that point (they did not invent a new, non-standard key usage flag for ‘offline CRL signing’).
All of the above is the normal interpretation of certificates. It so happens that, as far as standards are concerned, ‘root CA certificates’ do not exist. A ‘root’ is called a trust anchor and consists of, mostly, a name (DN) and a public key. It is traditional to encode trust anchor as ‘certificates’, i.e., a sequence of bytes which follow the encoding rules of certificates (such certificates are often self-signed because the format for a certificate has a non-optional slot for a ‘signature’, so there must be something in that slot).
Since this is non-standard, interpretation of certificate extension in such a certificate-like structure is open to local variants. Some implementations interpret the Key Usage extension in a root certificate in the ways explained above. Some ignore that extension altogether.
In general, it is safe (for interoperability) to fill root CA certificates with contents that would be perfectly valid if that ‘certificate’ was a real one, instead of a convenient encoding vessel for a trust anchor.