Optimizing the Revocation Experience

Leave the default revocation checking behavior to prefer OCSP revocation checking instead of using CRLs for revocation checking. If there are multiple OCSP URLs and multiple CRL distribution point URLs, the computer will try all OCSP URLs before it continues to attempt downloading CRLs from the CRL distribution point URLs. For more information about using Group Policy to define revocation checking behavior for computers running Windows Vista SP1 and Windows Server 2008, see Appendix A: Managing OCSP Settings with Group Policy.

Note
A computer will switch to using CRLs if the number of OCSP responses received from a specific issuer exceeds the default maximum of 50 (which is defined in “CryptnetCachedOcspSwitchToCrlCount” DWORD registry value in the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config registry key).

As discussed earlier in this paper, you can implement OCSP for certificates that do not have OCSP information in their authority information access extension. The issuing CA certificate can be added to a Group Policy object (GPO) linked to the domain, site, or organizational unit (OU) where the computer account exists. Group Policy lets you to designate one or more OCSP URLs for revocation information validation. When you implement the GPO:

• The OCSP URLs are only applied to the computers running Windows Vista SP1 or Windows Server 2008 that are affected by the GPO.
  
  
• The OCSP URLs added in the GPO take precedence over the existing OCSP URLs in the authority information access extension of a validated certificate.
  
  
• CRLs can be disabled for the CA, but we do not recommend doing this.
  
  

For more information about using Group Policy to define revocation checking behavior for computers running Windows Vista SP1 and Windows Server 2008, see Appendix A: Managing OCSP Settings with Group Policy.

Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

Instead of creating long listings of URLs for OCSP and CRL retrieval, consider limiting the lists to a single OCSP and a single CRL URL. Instead of providing multiple sites, work on ensuring that the sites referenced in the URLs are highly available and can handle the expected bandwidth requirements.

You must determine the validity period for CRL and OCSP responses based on your risk assessment. Generally, you should implement your CA so that it overlaps validity periods. For example, you could publish base CRLs daily with a validity period of two days. To determine the validity period for CRLs, use the following guidelines:

• The validity period for issuing CAs should be no less than 12 hours (especially if using LDAP URLs in AD DS).
  
  
• CRLs should not be updated more frequently than every eight hours.
  
  
• The validity period for CRLs at offline CAs is typically between three and six months.
  
  

Note
The CRL publication intervals must match the intervals defined in the organization’s Certification Practice Statement (CPS). For example, if the CPS requires monthly updates to the root CA’s CRL, then the CRL validity period must be one month.

We recommend minimizing the lifetime of OCSP signing certificates. The recommended lifetime is two weeks. The two-week recommendation is a balance between risk and the cost (and effort) of updating the OCSP signing certificates. Only a risk assessment can determine the optimal lifetime of OCSP signing certificates for your organization.

We also recommend that you enable the szOID_PKIX_OCSP_NOCHECK (1.3.6.1.5.5.7.48.1.5) extension in the OCSP signing certificate so that no revocation checking is performed on the OCSP signing certificate. This ensures that a CRL is not downloaded to validate the OCSP signing certificate.

Although NONCE values and digital signing improve the security of an OCSP request, they lead to less than optimal performance. Specifically:

• A NONCE is a unique identifier included in the OCSP request. The intent is to prevent a replay attack. If a NONCE is included, and the Online Responder is enabled to support NONCE, the OCSP responder will ignore a cached OCSP response. A new response is formulated and the response includes the NONCE to tie the response back to the original request.
  
  
• If a request is signed, the OCSP responder must again create and send a unique response to the OCSP client.
  
  

If NONCE or digital signatures are not allowed, the OCSP responder or a proxy can respond with a time-valid, cached response, resulting in better performance for revocation checking.

You should enable pre-fetch options at OCSP responders and proxy servers to allow pre-fetching of revocation information by computers running Windows Vista SP1 and Windows Server 2008. Generally, you should enable the following options:

• Ensure that the Web server is configured to implement the ETag field to enable conditional GETs using the If-None-Match header field. For IIS 7.0, the ETag field is enabled by default and configured to ensure that the same ETag is implemented if Internet Information Services (IIS) is deployed in an NLB cluster.
  
  
• Define the Cache Control: Max-age field to the time that a proxy or client is expected to cache the object.
  
  
• Set the Max-age to less than the overlap period between the old and the next copy of the object.
  
  
• Set a shorter Max-age value for long-lived CRLs. For example, for an offline CA, consider setting Max-age to one week to enable a client computer to determine whether an offline CA CRL is updated weekly.
  
  

For more information about implementing ETag and Max-age headers, see Appendix B: Configuring ETag and Max-Age in IIS.

If you are experiencing revocation checking problems with a computer running Windows Vista or Windows Server 2008, we recommend that you use CryptoAPI 2.0 diagnostics to troubleshoot the revocation settings. CryptoAPI 2.0 diagnostics provides administrators with the ability to troubleshoot PKI problems by collecting detailed information about certificate chain validation, certificate store operations, and signature verification. For more information about using CryptoAPI 2.0 diagnostics, see Troubleshooting PKI Problems on Windows Vista (http://go.microsoft.com/fwlink/?LinkID=89570).

Group Policy lets you define how revocation behavior will operate in your environment. With Group Policy, you can define:

• Custom URLs for verifying revocation status with OCSP for certificates that do not include OCSP URLs in the authority information access extension.
  
  
• Whether your environment prefers OCSP or CRLs for revocation status checking.
  
  
• Custom time-outs for CRL and OCSP retrieval.
  
  
• Extended lifetimes for CRLs and OCSP responses if a CA or OCSP Responder were to fail.
  
  

For more information about using Group Policy to define revocation checking behavior for client computers running Windows Vista SP1 and Windows Server 2008, see Appendix A: Managing OCSP Settings with Group Policy.