Certificate Status and Revocation checking discusses a few of these options.
Although I don't know why one would partition a certificate, there is some interesting support issue with regard to Windows clients and servers. Windows CA's don't support issuing partitioned CRLS at all.
When the Windows crypto system verifies a certificate it only checks
IssuingDistributionPoint values of
only ContainsCACerts. No other fields are supported. Furthermore,
IssuerAltName extensions in the will be ignored if non critical, or fail if marked critical as per RFC 3280.
Moreover in Windows, the “onlySomeReasons” and “indirectCRL” fields of the IDP are not supported.
CRL Reason Codes
The process of revocation invalidates a certificate before its end validity date using one of the CRL reason codes.
Note Windows does not support partitioning CRLs by reason code as either a server or a client. I don't have further information as to what software supports partitioning (as a server or client) or why one would need it
When a certificate is revoked, it is possible for a certificate issuer to specify why the action was taken. This is done by specifying a revocation reason; these reasons are defined by RFC 3280 and include the following:
Key Compromise The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen or a smart card is lost.
CA Compromise The token or disk location where the CA’s private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA’s private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.
Change of Affiliation The user’s relationship with the organization has been terminated, indicated in the DN attribute of the certificate. This revocation code is most often used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires a different certificate be issued by a departmental CA.
Superseded A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is most often used when a smart card fails, the password for a token is forgotten by a user, or the user’s legal name has changed.
Cease of Operation If a CA is decommissioned—no longer to be used—the CA’s certificate should be revoked with this reason code. Do not revoke the CA’s certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.
Certificate Hold A temporary revocation that indicates a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.
Note While CertificateHold allows a certificate to be “unrevoked”, it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.
RemoveFromCRL If a certificate is revoked with the CertificateHold reason code, it is possible to “unrevoke” a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL. This is specific to the CertificateHold reason and is only used in DeltaCRLs.
Unspecified While it is possible to revoke a certificate with the “Unspecified” reason code, it is not recommended, as it does not provide an audit trail as to why a certificate is revoked.