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.)
You can use .NET Server's Version 2 certificate templates to define policy restriction rules for user, machine, subordinate CA, and service certificates. (For more information about Version 2 certificate templates, see the sidebar "Version 2 Certificate Templates," page 52.) You must define all policy restrictions for cross-certification certificates through the capolicy.inf file.
Key Recovery and Archival Methods
Key recovery is a PKI's ability to recover lost or unavailable private encryption keys. As such, successful key recovery requires an efficient and secure key-archival system. Data recovery usually follows key recovery: After a user or authorized administrator gains access to the user's private key, the user or administrator can use the key to decrypt the encrypted symmetric keys with which the user encrypted persistent mail or file data.
Earlier Windows versions provide key recovery for two applications: the Encrypting File System (EFS) and the Secure MIME (S/MIME)—based secure mail application that ships with Microsoft Exchange Server. These applications use slightly different key-archival mechanisms: EFS stores the keys and encrypted file in NTFS, whereas Exchange uses a central key database. The .NET Server PKI builds on the central-database concept, providing a centralized key recovery service that any PKI-enabled application can use.
The .NET Server CA stores key-recovery data locally, in the CA database. The CA uses a symmetric key to encrypt an archived private key, then uses a key recovery agent's public key to encrypt the symmetric key. (A recovery agent is an account with key-recovery privileges.) The CA stores the encrypted private key in the CA database's RawArchivedKey column, then stores the encrypted symmetric key in the KeyRecoveryHashes column. An administrator can view these columns and the rest of the CA database's schema from the command line. To do so, type
An administrator's ability to recover private keys from the CA's recovery database depends on possession of a special key recovery agent certificate and private key. Like the Exchange Key Management Service (KMS), which manages the S/MIME key-recovery database, the .NET Server CA can support a "missile-silo" system for key recovery: The CA administrator can require multiple administrator key- recovery certificates to recover a key—a system that provides stronger security.
To configure a CA object's key-recovery settings, open the Microsoft Management Console (MMC) Certification Authority snap-in, open the CA object's Properties dialog box, then go to the Recovery Agents tab, which Figure 1 shows. Select the Archive the key check box to enable key recovery. Specify the number of key recovery agents you want to set up in the Number of recovery agents to use text box. Finally, select the accounts you want to use as key recovery agents (these accounts must have a key-recovery certificate and private key).
A full .NET Server CA key-recovery sequence consists of four steps. These steps are as follows:
You can use the Certificate Templates snap-in to enable key archival at the certificate-template level. To automatically archive the private key when a user requests a certificate based on a particular template, open the template, go to the Request Handling tab, and select the Archive subject's encryption private key check box. You can set the key-archival option only on Version 2 certificate templates.
User Autoenrollment
Win2K supports autoenrollment and renewal for machine certificates. Win2K IP Security (IPSec) tunnel endpoints and domain controllers (DCs) can use this feature to automatically get and renew certificates. .NET Server extends the autoenrollment feature to users, greatly enhancing the PKI's ease of use. This feature requires extra client-side code; that code is currently bundled only with XP clients.
To set up user autoenrollment, you must make configuration changes in both the MMC Certificate Templates and MMC Group Policy snap-ins. To enable autoenrollment at the template level, open the Certificate Templates snap-in, open the template, go to the Security tab, and set the appropriate ACL settings to give users or groups the Autoenroll permission. To enable autoenrollment at the GPO level, open the Group Policy snap-in, drill down to Computer Configuration\Windows Settings\Security Settings\Public Key Policies, then open the Autoenrollment Settings Properties dialog box, which Figure 2, page 53, shows. (As in Win2K, you enable machine autoenrollment from the GPO Public Key Policies' Automatic Certificate Request Settings container.)
User autoenrollment occurs by default when the user logs on to the domain. A user can also force immediate enrollment. To do so, the user opens the MMC Certificates snap-in, opens his or her personal certificates container (i.e., the Current User or My User Account container), selects Actions, All Tasks, Automatically Enroll Certificates from the menu bar. Each time user autoenrollment occurs, a warning balloon appears in the user's system tray. When the user clicks this balloon, a dialog box appears and prompts the user to choose whether to start the autoenrollment process.
Delta CRLs
Win2K PKI's method of supporting CRLs has several disadvantages. The CRLs tend to be huge because revocation information accumulates in each CRL. Win2K CRLs support versioning, but a new version automatically inherits all revocation information from the preceding version, so a CRL becomes no smaller until a certificate expires. Also, each new CRL version causes the client to download the complete CRL, which isn't an efficient use of network bandwidth. As a result, many administrators configure longer CRL lifetimes (CRLs are cached on the client side for their entire lifetimes). But long CRL lifetimes reduce the revocation information's timeliness because new revocation information isn't immediately available.
To resolve these problems, the .NET Server PKI embeds support for delta CRLs. As Figure 3 illustrates, delta CRLs are relatively small CRLs that contain only the revocation changes that have occurred since the most recent base CRL. Because delta CRLs are small, PKI clients can download them regularly, and the CA can provide more accurate revocation information to its clients. You configure delta CRL settings in the CA's Revoked Certificates container's Properties dialog box, which you can access from the Certification Authority snap-in.
PKI for the Masses
I've described some of the most important new .NET Server PKI features, but more exist. For example, this PKI also provides enhanced role separation and administration delegation, compliant with US Common Criteria IT security standards. The .NET Server CA offers enhanced auditing options. And the PKI includes CAPICOM, a COM object that developers can use to easily provide cryptographic functions (e.g., signing, certificate store manipulation) to PKI-enabled applications.
One thing that hasn't changed (and a competitive ace that Microsoft will continue to play) is the low cost of the Windows PKI products. However, Microsoft's CA software is included only with Windows .NET Enterprise Server (formerly Windows 2000 Advanced Server) and Windows .NET Datacenter Server.
Although the .NET Server PKI might not offer all the capabilities of more advanced products, its affordability might make it attractive to a lot of smaller companies. Given the .NET Server PKI's low cost and enhanced features, it might well be the product that brings PKI to the masses. Although Windows PKI isn't proven technology—an important requirement for success in enterprises with high-end security requirements—the software will probably prove itself as it matures over the years and as more organizations adopt it. In the meantime, this upgrade to the Windows PKI is worthy of serious consideration.
