PKI-Enabled Application Revocation Checking Support
Not all Windows PKI-enabled applications automatically perform revocation checking. Also, revocation checking is sometimes dependent on an application-specific configuration setting. Table 1 provides an overview of how the most commonly used Windows PKI-enabled applications support revocation checking.
To enable revocation checking for Secure MIME (S/MIME) in Microsoft Outlook 2000 Service Release 1 (SR1), open the registry on the client, navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography{7801ebd0-cf4b-11d0-851f-0060979387ea} registry subkey, create a new entry called PolicyFlags (of type REG_DWORD), and set its value to 00010000. To enable revocation checking for IP Security (IPSec) in Win2K Service Pack 2 (SP2) and later, open the registry, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley registry subkey, create a new entry called StrongCrlCheck (of type REG_DWORD), and set its value to 1 or 2. This registry entry's values have the following meanings:
- 0—Disables CRL checking for certificate-based IPSec authentication.
- 1—Enables CRL checking and fails the certificate-validation process only if the CRL explicitly shows that the certificate is revoked. The client system will ignore all other failures, including when the CDP URL is unavailable.
- 2—Enables CRL checking and fails certificate validation on any CRL check errors.
Automated Revocation Checking
In the PKI world, different models are available for automated revocation checking. Most, with the exception of certificate revocation trees and the Online Certificate Status Protocol (OCSP), are based on complete CRLs, authority revocation lists, CDPs, enhanced CRLs, delta CRLs, and indirect CRLs. I don't have room to discuss all these methods, but for a good overview of automated revocation- checking methods, see Carlisle Adams and Steve Lloyd, Understanding Public-key Infrastructure: Concepts, Standards, and Deployment Considerations (Que Publishing, 1999).
As I mentioned earlier, Win2K PKI supports complete CRLs and CDPs. Windows 2003 PKI adds support for delta CRLs. Windows 2003 and Win2K also support specific Netscape revocation extensions.
A revocation requirement often mentioned in the IT industry is support for OCSP. As RFC 2560 defines, OCSP offers real-time certificate revocation information to all PKI users. Neither Windows 2003 nor Win2K supports OCSP out of the box. However, you can add support by using third-party software from vendors such as Alacris or Valicert (a division of Tumbleweed Communications). CDPs and delta CRLs offer a native Windows alternative to using OCSP.
CRL Distribution Points
CDPs offer a convenient way to automate revocation checking. Each certificate that a Windows 2003 or Win2K CA generates can include one or more CDPs. The CA stores CDPs in an X.509 certificate extension that it generates. A CDP can be an HTTP URL, a Lightweight Directory Access Protocol (LDAP) URL, or a file share. After the CA issues a certificate, you can't modify that certificate's CDPs. Figure 4 illustrates how CDPs work. The Certificate Server issues the certificate (shown in the figure connected by a dotted line) to the PKI clients and issues the CRLs (shown connected by a dashed line) to the CDPs. The certificate's CDPs point to the different CDP locations from which the client can download the CRLs.
A Windows PKI-enabled application that doesn't find a local copy of the complete CRL or delta CRL will check the certificate's CDPs for an up-to-date complete CRL or delta CRL. If a complete CRL or delta CRL is available from the CDPs, the application will download the CRL and cache it locally for the lifetime of the CRL. If the certificate doesn't contain any CDPs, the application will query the certificate's issuing CA for a complete CRL or delta CRL.
For CDPs to function correctly, not only is certificate and PKI-enabled application support required, but the CA must also support them. The CA must have an exit module that can publish the complete CRLs and delta CRLs to the appropriate file system, Web, or Active Directory (AD) CDP. By default, every Windows 2003 and Win2K CA includes an exit module that can handle CRL publication. Neither Windows 2003 nor Win2K can automatically publish complete CRLs or delta CRLs to HTTP CDPs—however, you can publish these types of CRLs manually.
Besides automated revocation checking, CDPs also can increase complete CRL and delta CRL availability. Each certificate can contain multiple CDPs so that if one CDP is unavailable, the PKI logic will try another CDP.
To configure the contents of a certificate's CDP fields, open the Certification Authority snap-in, right-click a Windows CA object, select Properties from the menu, then click the Extensions tab, which Figure 5 shows. To add a new CDP to the certificates that the CA issues, click Add. Table 2 describes the CDP-specific flags located at the bottom of the Extensions tab. You can configure the CDP field of a CA's proper certificate by using a capolicy.inf configuration file.
A convenient way to test CDPs embedded in a Windows X.509 certificate extension is to use the URL Retrieval Tool, which Web Figure 2 shows and which comes with the Windows 2003 version of the Certutil command-line tool. To access the URL Retrieval Tool, type
certutil -URL <certificate_
file_name>
To retrieve complete CRLs and delta CRLs, select the CRLs (from CDP) option in the Retrieve section, then click Retrieve. Double-clicking one of the rows in the upper part of the URL Retrieval Tool opens the CRL viewer for the selected CRL. You can also use the URL Retrieval Tool to retrieve CA certificates mentioned in a certificate's Authority Information Access (AIA) field.
Netscape Revocation Extensions
Netscape uses a proprietary online certificate revocation checking method. The company embeds a custom extension, netscape-revocation-url, in all its certificates. Netscape-revocation-url points to a Web page that checks the certificate revocation. To send the revocation-checking request to the Web page, Netscape uses the HTTP GET method with a URL that concatenates netscape-revocation-url and the serial number of the certificate that needs to be checked. The response that comes back from the Web server is a document with Content-Type application/x-Netscape-revocation. The document contains one digit (either 1 if the certificate isn't valid or 0 if the certificate is valid). To enable a Windows 2003 or Win2K CA to issue certificates containing this extension, you must use the Certutil tool. From the command line, type
certutil -setreg Policyrevocationtype +AspEnable
You must also restart the CA service to make this change effective.
A Crucial PKI Service
Certificate revocation checking is a crucial PKI service, and reliable revocation checking is an important part of a trustworthy PKI service. Make sure you address revocation checking when you design your PKI environment. Both Windows 2003 and Win2K let you automate the certificate-revocation process, and Windows 2003 PKI includes some important enhancements in the revocation-checking space, so use them.