First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks about a certificate C is something that comes from the issuer of C. Since a root CA has no issuer, it cannot be revoked.
In other words, if your root CA is compromised, you are in deep trouble. This is why people who are serious about certificates use a three-level structure:
A root CA is created and maintained on an offline machine, that is kept in a safe or some shielded room. It is powered regularly (say, on a monthly basis) to sign a CRL, but that's about all.
An intermediate CA is awarded a certificate by the root CA, as a one-time procedure.
All user certificates are issued by the intermediate CA.
If the intermediate CA is compromised (which is conceivable, since it is used often and thus is probably part of a network), then the root can still issue a CRL that revokes that intermediate CA.
That being said, you should consider that there are two PKI instances at work in your case. With SSL/TLS and client certificates:
- The server owns a certificate, that the client validates.
- The client owns a certificate, that the server validates.
These two certificates may live in separate world, issued by distinct CA.
For the server certificate, you need the client to have access to all information required to make sure that the server certificate is valid, and this includes regularly issued CRL or something equivalent (OCSP responses...). I suppose here that you do not issue that certificate yourself; instead, you buy an "SSL certificate" from some commercial CA, because the root CA is already distributed in all client systems, and that CA issues and publishes CRL.
Now let's see about the client certificates. These certificates are to be validated by your server. And you are also the one who will decide which certificates are to be revoked. In other words, any CRL here would be a mechanism by which you will agree with yourself. In that sense, this is entirely your business and you can fulfil that functionality in any way as you see fit. For instance, you could maintain, on the server, some SQL table that lists the thumbprints of client certificates that are to be rejected, and revocation would simply be adding an entry in that table. When you talk to yourself, you do not necessarily need to sign your mental messages !
Regardless, you still need the ability to revoke certificates, or something similar. At this point, you must understand that there is a difference between authentication (making sure that the client who talks to you is Bob) and authorization (deciding what Bob should be allowed to do). Suppose that Bob's private key is compromised:
Since Bob's key may be in the wrong hands, you can no longer accept Bob's certificate as a proof of Bob's identity. That certificate should be "cancelled" in some way (e.g. revocation).
Since certificate revocation is asynchronous, you also need a "fast block" system that will keep any purported Bob out of the system immediately. This is done on the authorization layer: you temporarily "disable" Bob's account, or set his access rights to "nothing".
Bob is still Bob, though, a (possibly paying) customer. He will want to connect again, and it should work. Therefore, Bob's access rights will have to be enabled again. However, you should do that only when Bob has been issued a new certificate (with a new public/private key pair, of course) and Bob's old certificate is now rejected by your server.
Therefore, you really need, in all generality, a way to reject certificates that would otherwise look fine. Revocation is such a way; another one is to issue only very short-lived certificates (valid for, say, one week at most), but this requires pushing new certificates to clients on a daily or weekly basis, and client software is not necessarily up to such a task. The normal method is thus to issue long-lived certificates to clients (valid for one or a few years) and to maintain, on the server side, a mechanism that allows arbitrary rejection of certificates. Conceptually, that mechanism is as simple as having a list of "undesirable certificates" that the server consults. A CRL is a standard formatting for such a list, that the issuing CA signs to allow transport over unsecured mediums. However, as explained above, this list is to be transferred between your CA and your server, which may be the same machine, and do not necessarily need such a signature.
