Planning Your Public Key Infrastructure

Define Certification Authority Trust Strategies

Before deploying a Windows 2000 PKI, you need to define the CA trust strategies you want to use in your organization. With Windows 2000, you can establish trust for CAs using hierarchical CA trust chains and certificate trust lists.

Benefits of Certification Authority Trust Hierarchies

The Windows 2000 PKI has a hierarchical CA model. A CA hierarchy provides scalability, easy administration, and consistency with a growing number of third-party CA products.

In general, a hierarchy will contain multiple CAs with clearly defined parent-child relationships. In this model, subordinate CAs (children) are certified by (parent) CA-issued certificates, which bind a CA's public key to its identity.

The CA at the top of a hierarchy is referred to as a root CA. The CAs below the root in the hierarchy are referred to as subordinate CAs. In Windows 2000, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities store), you trust every subordinate authority in the hierarchy, unless a subordinate authority has had its certificate revoked by the issuing CA or has an expired certificate. Thus, any root CA is a very important point of trust in an organization and should be secured and maintained accordingly.

The advantage of this model is that verification of certificates requires trust in only a small number of root CAs. At the same time, it provides flexibility in terms of the number of certificate-issuing subordinate CAs. There are several practical reasons for deploying multiple subordinate CAs. These include:

Usage. Certificates can be issued for a number of purposes (for example, secure e-mail, network authentication, and so on). The issuing policy for these uses might be distinct, and separation provides a basis for administering these policies.

Organizational divisions. There can be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.

Geographic divisions. Organizations might have entities at multiple physical sites. Network connectivity between these sites might dictate a requirement for multiple subordinate CAs to meet usability requirements.

Multiple trust hierarchies also provide the following administrative benefits:

Flexible configuration of the CA security environment (key strength, physical protection, protection against network attacks, and so on). You can tailor the CA environment to provide a balance between security and usability. For example, for a root CA, you can use special-purpose cryptographic hardware, maintain it in a locked vault, and operate it in offline mode. However, for an issuing CA, this same setup would be costly, make the CA difficult to use, and reduce the performance and effectiveness of the CA.
The ability to frequently renew keys and certificates for those intermediate and issuing CAs that are at high risk for compromise, without requiring a change to established root trust relationships.
The ability to turn off a subsection of the CA hierarchy without affecting established root trust relationships or the rest of the hierarchy.

In addition, deploying multiple issuing CAs provides the following benefits:

Separate certificate policies for different categories of users and computers, or for organizational and geographic divisions. You can set up an issuing CA to provide certificates to each distinct category, department, or site.
Distribution of certificate load and provision of redundant services. You can deploy multiple issuing CAs to distribute the certificate load to meet site, network, and server requirements. For example, slow or noncontinuous network links between sites can require issuing CAs at each site to meet certificate services performance and usability requirements. You can deploy issuing CAs to distribute certificate load as necessary to meet all site and network connectivity and load requirements. You can also deploy multiple issuing CAs to provide duplicate services. So if one CA fails, another issuing CA is available to provide uninterrupted service.

Benefits of Certificate Trust Lists

A certificate trust list is a list of self-signed certificates for the CAs whose certificates are to be trusted by your organization. A certificate trust list allows you to control the purpose and validity period of certificates issued by external certification authorities beyond what the certification authority specifies. Whenever you create a certificate trust list, you need to authorize it by signing the certificate trust list with a certificate issued by an already trusted certification authority.

There can be multiple certificate trust lists existing for a site. Because the uses of certificates for particular domains or organizational units (OUs) can be different, you can create certificate trust lists to reflect these uses, and assign a particular certificate trust list to a particular Group Policy object.

When you apply the Group Policy object to a site, domain, or OU, the policy is inherited by the corresponding computers. These computers then trust the CAs in the certificate trust list. You can also place the root CAs into Group Policy. Certificate trust lists are more convenient than using Group Policy because they expire.

You can create Windows 2000 certificate trust lists to provide the following benefits:

Creation of trust certificates from specific CAs without requiring broader trust for the root CA. For example, you can use certificate trust lists on an extranet to trust certificates issued by certain commercial CAs. Users with certificates issued by the trusted commercial CAs can be granted permission to access restricted extranet resources by mapping the certificate to an account stored in Active Directory.
Restriction of the permitted use of certificates issued by trusted CAs. For example, certificates issued by a CA might be valid for secure e-mail, network authentication, and signing software code. However, you can use a certificate trust list on an extranet to restrict the permitted use of certificates to secure mail only.
Control over how long third-party certificates and CAs are valid. For example, a business partner's CA can have a lifetime of five years and issue certificates with lifetimes of one year. However, you can create a certificate trust list with a lifetime of six months to limit the time that certificates issued by the business partner's CA are trusted on your extranet.

Additional Considerations for Certification Authority Trust Strategies

Keep the following considerations in mind when defining your CA trust strategies:

The depth of CA trust hierarchies is typically four levels (root CA, intermediate CA, issuing CA, and issued certificates).
Third-party CAs can form all or part of the CA trust hierarchies, but to ensure that third-party CAs will provide the expected interoperability, test your proposed hierarchies in the lab.
Some third-party products might require other CA trust models that might not be interoperable with rooted CA hierarchies. Windows 2000 and most commercial CAs support rooted CA hierarchies.