The most fundamental question in a public key infrastructure (PKI) is, "Which public keys are trustworthy?" The answer to that question starts with trust in a Certification Authority (CA). When you trust a CA, you expect that CA to create legitimate certificates that uniquely bind information about an individual to a public key. You also expect the CA to verify the individual's identity and determine whether his or her private key is stored securely—before the CA issues a certificate.
PKI trust models provide a technological framework for managing the trust relationships between CAs and PKI users and between CAs. A CA's trust domain defines the organizational or geographical boundaries within which the CA is considered trusted. One organization might be divided into different trust domains according to, for example, the organization's divisions or departments. All PKI users in a CA's trust domain consider the CA a trust anchor—a CA that the PKI user explicitly trusts under all circumstances. During certificate validation, PKI software tries to discover a trust path that reaches to the level of a trust anchor CA.
Windows Server 2003 PKI supports two main PKI trust models: the hierarchical trust model and the networked trust model. Windows 2003 PKI also features built-in support for constrained PKI trust relationships, which let CA administrators qualify trust relationships between CAs.
Hierarchical Trust Model
The hierarchical PKI trust model, which consists of a tree of CAs, is typically used to define PKI trust relationships within one organization. Organizations that have a clear hierarchical structure can often easily be mapped to this type of model.
In a hierarchical trust model, a clear superior-subordinate relationship exists between CAs on different hierarchical tiers. At the top of the hierarchy is a root CA—typically the trust anchor of the hierarchy. Within a hierarchy, the root CA is the only entity authorized to sign its own certificate. The self-signed root certificate makes it impossible for anyone to pretend to be the root CA; only the root CA knows and possesses its private key. The root CA certifies the tier-1 CAs (one tier below the root), which in turn certify the tier-2 CAs, and so on.
Figure 1 shows a sample hierarchical PKI trust model comprising three levels of CAs: the root CA level, an intermediate CA level (based on the organization's geographical locations), and an issuing CA level (based on the organization's divisions). The hierarchical trust model supports delegation: A superior CA can delegate part of its certificate-issuing responsibilities to a subordinate CA. In a strict hierarchy, subordinate CAs (i.e., non root CAs) have only one superior CA. A hierarchy can contain two types of subordinate CAs: issuing and intermediate. Issuing CAs issue certificates to PKI users, whereas your intermediate CAs should (as a best practice) issue certificates only to subordinate CAs. This approach lets you take intermediate CAs offline to provide an additional level of CA security.
When validating a certificate issued by a CA that's part of a hierarchical trust model, the PKI client software attempts to discover a trust path that links the issuing CA to the CA trust anchor. Windows 2003, Windows XP, and Windows 2000 PKI clients all support the necessary trust-path discovery and traversal mechanisms in a hierarchical trust model.
You define a hierarchical trust relationship between a superior CA and a subordinate CA during the Windows 2003 CA installation process. The Windows Components Wizard's CA Type dialog box, which Figure 2 shows, lets you select whether the CA will be a root CA or a subordinate CA. When building a CA hierarchy, you should use standalone CAs for the root CA and intermediate (i.e., nonissuing) CAs. Doing so will facilitate taking these CAs offline. The issuing CAs can be Windows 2003 enterprise CAs, which are integrated with Active Directory (AD).
For a subordinate CA, the CA installation process offers two choices. The first choice is to submit a certificate request, which is a *.req file that contains a Public-Key Cryptography Standards #10 (PKCS #10) or Certificate Management protocol with Cryptographic Message Syntax (CMS)-formatted request blob, directly to the parent CA (if the CA is published in AD and online). The second choice is to provide the request to the parent CA manually (e.g., using a 3.5" disk).
The Networked Trust Model
A networked trust model (aka a peer-to-peer—P2P—model or distributed trust model) has no superior-subordinate relationships between different CAs—all CAs are considered peers. The networked trust model is typically used to define PKI trust relationships between organizations. You can choose one of two methods—certificate trust lists (CTLs) or cross-certification—to set up trust relationships in a P2P model. Windows 2003 PKI supports both methods, whereas Win2K PKI supports only CTLs.
A CTL is a signed list of trusted CA certificates that's centrally managed by a PKI administrator and distributed throughout the organization to all PKI clients. You use a Group Policy Object (GPO) setting to define CTLs. In Windows 2003 PKI and Win2K PKI, you can limit a CTL's validity period and you can configure its scope to a limited number of PKI-enabled applications.
Cross-certification simply means that a CA issues a certificate to and can receive a certificate from another peer CA. A cross-certification trust relationship can be one-way or two-way (i.e., the CAs cross-certify each other). Figure 3 shows a networked PKI trust model set up between organizations.
Windows 2003 PKI clients and XP PKI clients support the necessary trust-path discovery and traversal mechanisms for a networked trust model made up of several cross-certifications. These mechanisms aren't available on Win2K PKI clients. When validating a certificate issued by a CA that's part of a networked trust model, the PKI client software will try to discover a trust path that links the issuing CA to its local CA trust anchor.
Contrary to setting up a hierarchical trust relationship, you can set up a cross-certification trust relationship any time after the CA installation. However, you can't set up a cross-certification trust relationship from the Windows PKI graphical interface; you must do so from the command line by using the certreq.exe utility. The instructions for setting up a cross-certification trust relationship are available in the Windows 2003 product documentation and in the Microsoft white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx.