Hi S-1-1-0, PS Crypto Guy is again on the board! Today I want to discuss about implementing Online Responder for Root and Policy CAs.

Abstract

Online Responder implements Online Certificate Status Protocol (OCSP) as a part of alternate certificate validation mechanism (or revocation provider). Classic PKI uses Certificate Revocation Lists (CRL) to provide an information about revoked and untrusted certificates issued by the particular Certification Authority (CA). Most applications perform certificate checking for revocation by downloading and examining the particular issuer's CRL (or CRLs). If the presented certificate's serial number is listed in the corresponding issuer's CRL, an application rejects that certificate. During the CA lifecycle, you sometimes revoke some unnecessary and untrusted certificates. For example, if a certificate holder lost his/her certificate and associated private key, or a user left the company. Each revoked certificate's serial number is added to the CRL.

When you setup a new fresh CA server, an initial CRL is about 500 bytes in size. Each revoked certificate increases this size by about 30-80 bytes. If you revoke 1,000 certificates, a CRL size will increase by 30-80kb. In large environments this number of revoked certificates can be reached quite quickly. This cause network overload and certificate validation delays due to regular CRL transmission over the network and additional client resources (CPU) is used to decode large binary CRL.

To address this issue, a OCSP was introduced. OCSP assumes client-server communications consuming fixed size — about 2kb regardless of CRL size. The CRL can be 1mb large (or even more), but OCSP communications still takes about 2kb for each certificate being validated. OCSP greatly reduce network load and certificate revocation delays.

Source of the problem

Since Windows Server 2008 implements Online Responder role, many administrators started Online Responder deployment within their private PKIs. In most cases, Online Responder is implemented for all CAs in the particular PKI, including Issuing, Policy (if any) and Root CAs. There is nothing wrong with such configuration, but it is really useless to implement Online Responder for offline CAs — Policy and Root. This is because, these CA roles issue certificates only to the subordinate CAs and not to other entities. While user and computer certificates are revoked quite frequently, it is unlikely to have many revoked CA certificates. Therefore Root and Policy CAs maintain an empty (or with only few revoked subordinate CA certificates) CRL.

As said, a OCSP is intended to reduce large CRL retrieval and decode delays. Since empty CRL is about 500 bytes, there are no performance or any other benefits. Moreover, OCSP communication consumes more traffic, than empty CRL retrieval. Also, this causes additional administrative overhead in additional Online Responder configuration management.

And remember, that OCSP is not a classic CRL replacement, just additional revocation provider and there are no strict requirements to implement OCSP for all CAs in the PKI. Ok, you can say, that some guys from VeriSign have implemented Online Responder for Root CAs too (while their CRLs are empty) — http://evsecure-crl.verisign.com/pca3-g5.crl. I doubt that you are a large CA provider as VeriSign with active certificate support in worldwide.

Conclusion

By summarizing this post, we can conclude that Online Responder should be implemented for those CAs which have quite large CRLs or there is a tendency for CRL growing — most likely Issuing CAs, that issue certificates to end entities (users and computers). There are no benefits (at all) in implementing Online Responder for less active CAs that issue certificates only to other CAs. Therefore, you should not implement Online Responder for these CA roles unless there is a special requirement in the external certificate/security policy.