CA Trust Relationships in Windows Server 2003 PKI

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.

Constrained Trust
Windows 2003 PKI's support for constrained PKI trust relationships, or what Microsoft calls qualified subordination, lets CA administrators put constraints on trust relationships between a CA and its subordinate CAs (in a hierarchical trust model) or between peer CAs (in a networked trust model). This ability to qualify trust relationships aligns PKI trust more closely with real-life trust: In reality, trust is rarely complete and is usually subject to certain conditions.

You define trust constraints by embedding specific X.509 certificate extensions in a subordinate CA's certificate or a peer cross-certified CA's certificate. Windows 2003 PKI supports the basic, name, issuance policy, and application policy trust-constraint-related certificate extensions.

Basic constraints. Basic constraints are based on an X.509 certificate extension called Basic Constraints, which can contain a field called pathLenConstraint (or path-length constraint). You can use this field only when the Basic Constraint X.509 certificate extension's ca field is set to true—which is the case only for a CA certificate. The path-length constraint sets the maximum number of non-self-issued CA certificates that can follow a certificate in a certification path, so you can use it to limit the length of the certificate chain.

Figure 4 shows two sample hierarchical trusts: Config 1 and Config 2. In Config 1, a basic constraint in the Level 1 subordinate CA's certificate limits that certificate's path length to 1. As a consequence, the CA located one level below that CA can't issue CA certificates, only end-user certificates. Config 2 obtains the same result by adding a path length constraint of 2 to the root CA's certificate. In that case, the PKI software automatically adds a path-length constraint of 1 to all subordinate CA certificates that the root CA issues.

Name constraints. You can set a name constraint certificate extension only in a CA certificate. The name constraint lets you restrict the population to which a subordinate or cross-certified CA can issue certificates. You can use name constraints to specify a namespace within which the subject names and subject alternate names in a certificate request, or the IP addresses that issued the certificate request, must be located. The constraints reside in the CA certificate's Name Constraints extension. Table 1 lists the name constraint types that Windows 2003 PKI supports. The table also lists the Internet Engineering Task Force (IETF) Request for Comments (RFC) standards that define each type.

In accordance with RFC 3280, a certificate Name Constraint extension specifies a namespace within which all subject names in subsequent certificates in a certification path must be located. As a consequence, a subordinate CA can only reduce—never extend—the namespace rule it receives from its parent CA. For example, if a subordinate CA is permitted to issue certificates for users in the research.hp.com DNS domain, that CA can never issue a subordinate CA certificate that permits that subordinate CA to issue certificates for users in the hp.com DNS domain.

In the hierarchical trust example that Figure 5 shows, you see that a name constraint can contain both exclusive and inclusive rules. During name constraint validation, exclusive rules always have precedence over inclusive rules. In the example, a name constraint in subordinate CA 1's certificate excludes the user principal name (UPN) @abc.com and permits the DNS names .hp.com and .compaq.com. When CA 1 receives a certificate request for [email protected], it will reject the request. If a request comes in for webserver1.hp.com, CA 1 will accept the request. Subordinate CA 2's namespace is even more restricted: CA 2 can issue certificates only in the .compaq.com DNS namespace. As a consequence, when CA 2 receives a request for webserver2 .hp.com, it rejects the request. If CA 2 receives a request for mail.compaq .com, it will accept the request.

Issuance policy constraints. An issuance policy defines the conditions that were met when the certificate was issued. In a Windows 2003 certificate, an issuance policy is identified by using its corresponding Object Identifier (OID) and is kept in a certificate's Certificate policies extension.

When you add issuance policy constraints to a CA certificate, they define the set of issuance policies that will be included in any certificate that the CA issues. You can include the constraints in cross-certification CA certificates to limit the trust you have in the certificates that a cross-certified CA issues. The enforcement of an issuance policy constraint extension relies on the certificate chain validation logic. This logic is available only in Windows 2003 and XP.

When you include issuance policies in a certificate issued to a PKI user, policy enforcement must be performed at the level of the PKI-enabled application. The PKI-enabled application must check to determine whether it permits a certificate issued under a certain issuance policy. Thus, the application must be intelligent enough to know which issuance policies it supports.

Windows 2003 PKI comes with four predefined issuance policies. Table 2 shows each policy's corresponding OID and function. The a, b, c, and d variables in the OID for the low, medium, and high assurance issuance policies represent a randomly generated value that's unique for every Windows 2003 forest. You can also define your own policies, depending on the needs of your PKI environment or application.

Figure 6 shows the effect of setting issuance policies in an end-entity certificate, in this case the low assurance issuance policy (which is inherited from the issuing CA at Level 1). When the certificate is used in a PKI-enabled application requiring a high assurance issuance policy, the certificate will be rejected; it can be used only in PKI-enabled applications that require a low assurance issuance policy.

Application policy constraints. An application policy constraint limits the applications for which a certificate can be used. You can set an application policy in both CA (hierarchical and cross-certified) and end-entity certificates. Like issuance policies, application policies are identified by using the OID of the corresponding policy. These policies are kept in a certificate's Application policies extension. Web Table 1 (http://www.winnetmag.com/windowssecurity, InstantDoc ID 42444) lists the Windows 2003 PKI predefined application policies and their corresponding OIDs.

In Version 2 certificates, which Windows 2003 introduced, application policies have the same function as the Win2K extended key usage (EKU) certificate extension. Version 2 certificates are generated by an enterprise CA based on a Version 2 certificate template. For downlevel compatibility, Windows 2003 CAs and Windows 2003 and XP clients can still work with the EKU extension.

As I mentioned, you can set application policies in both end-entity certificates and CA certificates. If you set an application policy in an end-entity certificate, you limit the applications for which the certificate can be used. If you set the policy in a CA certificate, the policy will be copied in all certificates (end-entity and CA) the CA issues and will thus limit the applications for which those certificates can be used. Setting the policy in a CA certificate will also limit the certificate types a CA can issue. For an enterprise CA, the application policy settings even overrule the certificate templates that are loaded in its Certificate Templates container. For example, if you want a subordinate CA to issue user certificates, you need to make sure that you add the application policy OIDs for the Encrypting File System (EFS), Secure Email, and Client Authentication. The User certificate template covers all three application policies.

Application policies that are set in cross-certification certificates limit the applications for which a certificate with the cross-certificate in its certificate chain can be used. In this case, enforcement of the application policy is the certificate chain validation software's responsibility. Again, the code needed to validate the application policy is available only in Windows 2003 and XP.

Figure 7 shows the effect of setting application policies in CA certificates. The figure shows that an application policy has been set in the certificates of subordinate CA 1 and CA 2. Subordinate CA 1 will accept both email and Secure Sockets Layer (SSL) certificate requests. Subordinate CA 2 can issue only email certificates and will reject SSL certificate requests.

Defining Trust Constraints
Windows 2003 PKI offers three tools to define PKI trust constraints: the capolicy.inf configuration file, the policy.inf configuration file, and the Microsoft Management Console (MMC) Certificate Templates snap-in.

During CA installation, you can use the capolicy.inf configuration file to set a CA certificate's PKI trust constraints. You can also use the configuration file to define other CA configuration settings, such as certificate revocation list (CRL) Distribution Points and Authority Information Access (AIA) locations. The content of the capolicy.inf file is checked for trust constraints at CA installation and every time the CA certificate is renewed. You need to store the file in the %systemroot% folder of the machine on which the CA is installed, and you can't change the file's name. You can use the capolicy.inf file to define only basic and issuance policy constraints.

The policy.inf configuration file defines the PKI trust constraints that are embedded in a CA certificate request file, and the Certreq utility uses this file as a parameter. Policy.inf is the most complete trust constraint configuration tool; contrary to the capolicy.inf file, you can use it to configure all the different categories of PKI trust constraints. As opposed to the capolicy.inf file, you can change the name of the policy.inf file.

You can use the Certificate Templates snap-in to create, modify, or delete certificate templates. Certificate templates define the properties (including the PKI trust constraints) of certificates issued by Windows CAs. You can modify the content of Version 2 certificate templates; you can't modify Version 1 certificate templates. Certificate templates don't offer the same level of granularity for PKI trust-constraint definition as is possible with a policy.inf configuration file: You can use templates to set only basic, application policy, and issuance policy constraints.

Flexible PKI Trust Definition
Trust is a fundamental PKI concept. Windows 2003 PKI's enhanced trust features make Windows PKI more powerful and flexible but also add more complexity to PKI trust design and administration. Still, no other security protocol or technology available today can define trust in such a granular way. In a future article, I'll look at how trust decisions are made and governed on the Windows PKI user side.