Is it a good idea to generate certificate-specific CRLs? What is this technique called?

Question

Suppose I create 3 certificates with the following CRLs

Cert1    http://crl.server.com/batch1/root1.crl    
Cert2    http://crl.server.com/batch2/root2.crl
Cert3    http://crl.server.com/batch3/root3.crl

Assume that the CRL is properly formed, the next update is valid, and is properly signed from the CA (here called "root"). The contents of the root*.crl only can ever contain one certificate. (assume the server software supports it, or the CRL is formed by an openssl command)

Question

Would this solve the following goals:

• "Hide" the revocation status of a certificate unless someone actually possesses it and therefore needs to know it. (Assume the word "batch" is an assigned GUID)

• Reduce the size of the CRL during ongoing maintenance

What are additional benefits drawbacks of this approach?

Are there other / better solutions that may address this need or incorporating CRL size reduction and or privacy?

What is this approach called?

(both goals of efficiency and privacy aren't requirements... this is a thought experiment for me)

Answer 1

Segmenting the space of certificates so that "partial" CRL can be computed is possible and supported, but it must be done properly. One base principle of CRL is that a CRL should be amenable to processing regardless of how it was obtained: that's the whole point of having signed objects. Since a certificate is considered as non-revoked by virtue of not appearing in the CRL, it must be possible to unambiguously verify whether a given CRL applies to a given certificate or not -- in X.509 terminology, whether the certificate is in scope of the CRL.

The extension to use is CRL Distribution Points -- see section 4.2.1.13 of RFC 5280. This extension has two distinct roles: it documents URL where CRL may be obtained, and it implements certificate space segmentation. For segmentation (that which you are interested in), the extension must be marked critical, and there must be a match between a "distribution point" and the corresponding structure in the Issuing Distribution Point extension of the CRL. In effect, each distribution point characterizes a sub-space of the certificate space; each certificate is marked with the sub-space to which it belongs, and each CRL is marked with the sub-space to which it applies. As with all things X.509, details are intricate and some thorough testing is needed in order to assess the reality of support by existing applications.

Such segmentation is useful for keeping CRL size low. It could be used to make single-certificate CRL, although this would have to be balanced with the cost of signing all these CRL (signatures are not expensive, but one million signatures can become a burden -- not really the signatures per se, but all the encoding and file transfer has some overhead).

You cannot expect much privacy gains that way: certificates are inherently public elements, which travel unprotected in many protocols. They cannot be considered secret. There is little more that can be obtained from CRL; actually, a full CRL is already discreet since it talks only about revoked certificates: it says nothing about unrevoked certificates and does not even hint at their existence.

Ultimately, single-certificate CRL already exist but are called OCSP responses.