PKI Comes of Age

With the release of Windows .NET Server (formerly code-named Whistler) planned for later this year, now is a good time to take a look at the OS's new public key infrastructure (PKI) capabilities. (This article assumes that you have a basic understanding of PKI and encryption technology. For a brief overview of the .NET Server PKI and other .NET Server and Windows XP security enhancements, see "Security in a Windows .NET Server Network," October 2001, InstantDoc ID 22248.) A PKI, which is rooted in asymmetric cryptography (i.e., cryptography that uses different keys for encryption and decryption), offers strong security services to internal and external users, computers, and applications. Such services are increasingly important in today's IT environment.

Microsoft's original Certificate Authority (CA) software, which became available as part of the Windows NT 4.0 Option Pack, is a basic PKI solution that many administrators use to generate Secure Sockets Layer (SSL) certificates. Windows 2000 contains an updated CA product that offers Active Directory (AD)—integration capabilities, enhanced scalability, and support for multilevel PKI hierarchies. Still, the Win2K CA software lacks important features, such as granular PKI-administration capabilities (e.g., the ability to delegate permission to an administrator to approve certificate issuance for only a specific group of users), advanced certificate- and CA-configuration features (e.g., features that let you change certificate-content layout or set advanced CA-auditing options), and the ability to easily build custom PKI-enabled applications to extend and reuse the PKI platform. These shortcomings might prevent large companies from deploying a Windows-based PKI.

The upcoming .NET Server PKI, which Microsoft has designed to work in conjunction with XP client systems, counters most of the drawbacks of earlier Windows PKIs. The .NET Server PKI supports cross-certification (as well as hierarchical certification), offers qualified subordination, enhances key archiving and key recovery, supports user autoenrollment, and provides delta certificate revocation lists (CRLs).

PKI Abilities Beyond the Enterprise
Early Windows PKIs provide a hierarchical CA trust model, which consists of multiple levels of CAs linked through parent CA/subordinate CA trust relationships. In such models, a parent CA issues certificates to its subordinate CAs. (Unlike the NT PKI, the Win2K PKI can support an unlimited number of CA levels; Microsoft has performed tests with as many 35 levels.)

The hierarchical CA model has an important drawback. You can't easily use the model to set up trust relationships beyond the boundaries of the enterprise. This inability exists primarily because the hierarchical model doesn't support qualified subordination—a mechanism that defines and enforces CA security policy rules from a parent CA to restrict the powers of a subordinate CA.

The .NET Server PKI supports both cross-certification and qualified subordination, thus providing an efficient way to set up certificate-trust relationships with your extranet partners' CAs. Your organization's CA can issue certificates to the CAs in your partner organizations, and vice versa. All parties can embed policy rules in their cross-certification certificate to limit its issuance and usage scope.

Cross-certification and secure extranets. The hierarchical PKI trust model isn't designed to set up trust relationships beyond the enterprise. Mapping a hierarchical PKI model to secure extranets is difficult. In a typical secure extranet setup, each participating organization uses its CA or CA hierarchy. Most of the organizations also have different CA security policies.

The only way to set up NT PKI interoperability between organizations is to include them in one hierarchy. Because all participants might already have a hierarchy or a CA in place, this requirement means you must completely rebuild the PKI trust infrastructure. With the Win2K PKI, you can also use certificate trust lists. CTLs are a Group Policy Object (GPO)—based feature that you can use to distribute CA certificates within a Win2K forest and to mark those certificates as trusted for a certain period of time or for certain PKI-enabled applications.

The .NET Server PKI's support for cross-certification provides a much more flexible way to secure extranets and define PKI trust relationships. In a CA hierarchy, certification is a one-way operation: A parent CA issues a certificate to a subordinate CA. In a cross-certification setup, certification is a two-way operation: Both CAs issue certificates to each other. The .NET Server PKI supports cross-certification in two basic forms. Qualified subordination occurs between CAs that are part of the same organization (or the same forest, in AD terminology); true cross-certification occurs between CAs that are part of different organizations (or different forests). For an overview of how cross-certification affects PKI users, see the sidebar "Cross-Certification and the PKI User."

Generating a .NET Server cross-certification certificate is a three-step process. First, you create a policy specification and embed it in a capolicy.inf configuration file. Capolicy.inf is a text-based configuration file that you need to create manually; you can easily edit this file in a text editor such as Notepad. You can store the file wherever you like, as long as you can access it through the Certreq command-line utility.

Second, you use Certreq, the capolicy.inf file, and a Public-Key Cryptography Standards #10 (PKCS #10)—formatted CA certificate request to generate a Cryptographic Message Syntax (CMS)—formatted message. (PKCS #10 and CMS are two standards that define the format of cryptographic messages.)

Third, the CA generates the cross-certification certificate using the CMS-formatted message. (For more information about cross-certification and qualified subordination, see updated information available at http://www.microsoft.com/windows.netserver.)

Qualified subordination and CA policy enforcement. In the Win2K and NT PKIs, the trust relationship between a parent CA and a subordinate CA is complete, meaning that after the parent CA issues a subordinate CA certificate, the subordinate CA can issue certificates—without restrictions. The .NET Server PKI provides qualified subordination, with embedded support for defining and enforcing name constraints, application policy, and issuance policies rules. (For a brief explanation of these rules, see the sidebar ".NET Server PKI Policy Rules," page 50.)