14.4 PKI trust models

In the following we will discuss the following PKI trust models: the hierarchical, networked, meshed, bridge CA, and hybrid trust models. Let’s first look at why we need multiple CAs.

14.4.1 Why multiple CAs?

Before diving into the nuts and bolts of PKI trust models, let’s examine why your organization may need more than a single CA. It is pretty obvious why we may need multiple CAs in an environment that’s made up of different organizations, but why would we need more than one CA in a single organization?

First of all, using multiple CAs limits the negative consequences of CA private key compromise. If your organization has a single CA and its private key is compromised, everyone in your organization will be affected. If your organization hosts multiple CAs, only the entities belonging to the CA’s trust domain will be affected. You may need multiple CAs for sizing, load balancing, and environmental or organizational reasons:

• Your organization may need too many certificates to be generated, issued, and maintained by a single CA.

• If many users need to get a certificate simultaneously, you may want to spread the request load by setting up multiple CAs.

• Geographical locations that are connected to a central location using a low-bandwidth link may all need their own CA.

• Your organization may need a different CA for every entity type with which it is dealing (e.g., one for partners, one for contractors, and one for employees).

Setting up multiple CAs also provides more flexibility:

• You can support applications that have different PKI security policy requirements. For example, you could have one certificate-based application dealing with large financial transactions and another with the distribution of corporate information. Both use certificates for client authentication, but the first one obviously needs a much higher level of user identification at certificate enrollment time than the second one. They also may have different backup scheme requirements and different CA key and certificate change interval requirements.

• You can map the PKI structure to the organizational structure more easily. Organizations often have departments with different PKI security policy requirements. Members of the human resources department usually must satisfy higher security requirements to get a certificate than members of the logistics department, who usually do not deal with confidential information.

• You can cope more easily with political and legal requirements. A part of your organization may require its own CA because it cannot tolerate any involvement of external people in its security-related services. The latter may also be imposed by legal requirements in certain environments.

14.4.2 Hierarchical trust model

A hierarchical trust model consists of a tree of CAs. The top of the hierarchy is a root CA—it is usually the trust anchor of the hierarchy. Within a hierarchy it is the only entity that is authorized to sign its own certificate. The self-signed root certificate makes it impossible for just anyone to pretend to be the root CA: Only the root CA knows and possesses its private key.

In a hierarchical trust model there is a clear superior-subordinate relationship between the CAs on the different hierarchical tiers. The root CA certifies the tier-1 CAs (one tier below), which in turn certify the tier-2 CAs, and so on. In a strict hierarchy every subordinate CA will only have one superior CA. The certificate issued by a superior CA to a subordinate CA is illustrated in Figure 14.3. The nonroot CAs in a hierarchical trust model are called subordinate CAs. A hierarchy can contain two types of subordinate CAs: intermediate CAs and issuing CAs. Issuing CAs issue certificates to PKI users. It is a best practice that intermediate CAs issue only subordinate CA certificates. This allows you to take intermediate CAs offline to provide an additional level of security.

Figure 14.3: A trust taxonomy: indirect trust relationships.

The hierarchical trust model supports delegation: A superior CA can delegate part of its certificate-issuing responsibilities to a subordinate CA. That is why organizations that have a clear hierarchical structure can usually easily be mapped to a hierarchical PKI trust model.

Windows 2000, Windows Server 2003, and Windows XP PKI clients all support the trust path discovery and traversal mechanisms that are needed in a hierarchical trust model (see Figure 14.4). When validating a certificate that has been issued by a CA that is part of a hierarchical trust model, the PKI client software will try to discover a trust path that links the issuing CA to the CA trust anchor. The latter may be a root CA or another CA in the hierarchy.

Figure 14.4: Hierarchical trust model.

When building a CA hierarchy using Windows Server 2003 PKI, you should use standa-lone CAs for the root and intermediate (every nonissuing CA). This will facilitate taking these CAs offline. The issuing CAs can be Windows Server 2003 enterprise CAs. The choice to make a CA a stand- alone or an enterprise CA is made when installing a Windows Server 2003 CA.

14.4.3 Networked Trust Model

In a networked trust model (illustrated in Figure 14.5), there are no superior-subordinate relationships between the different CAs. All CAs are considered peers. The networked trust model is also known as the peer-to-peer or the distributed trust model. In a networked trust model, trust anchors differ and a single CA will typically not be the trust anchor for the entire PKI community (like was the case for a hierarchical trust model). To set up trust relationships in this peer-to-peer community, two techniques can be used: cross-certification and certificate trust lists (CTLs). Whereas Windows 2000 PKI only supported CTLs, Windows Server 2003 supports both of them.

A CTL is a signed list of trusted CA certificates that is centrally managed by a PKI administrator and distributed throughout the organization to all PKI clients. In Windows 2000 and Windows Server 2003 PKI, CTLs can have a limited validity period and their scope can also be configured to a limited amount of PKI-enabled applications. We will come back to them more extensively in Section 14.5.2.

Cross-certification simply means that a CA issues a certificate for another peer CA and also the other way around. The ITU-T X.509 standard defines cross-certification as follows: “A certification authority may be the subject of a certificate issued by another certification authority. In this case, the certificate is called a cross-certificate…” and “Cross-certificate— This is a certificate where the issuer and the subject are different CAs. CAs issue certificates to other CAs either to authorize the subject CA’s existence (e.g. in a strict hierarchy) or to recognize the existence of the subject CA (e.g. in a distributed trust model). The cross-certificate structure is used for both of these.”

Figure 14.5: Networked trust model.

A cross-certification trust relationship may be one-way or two-way. In a two-way trust relationship, the certificate issued by the local CA for a remote CA is called the reverse cross-certificate. The certificate issued by the remote CA for the local CA is called the forward cross-certificate. The certificates issued in a cross-certification CA trust relationship are illustrated in Figure 14.6.

Figure 14.6: Cross-certification CA trust relationship.

Windows Server 2003 and Windows XP PKI clients all support the trust path discovery and traversal mechanisms that are needed in a networked trust model made up of several cross-certifications. These mechanisms are not available on Windows 2000 clients. When validating a certificate that has been issued by a CA that is 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. When building a networked trust model using Windows Server 2003 PKI, you can use either stand-alone or enterprise CAs.

The following two trust models, the meshed and the bridge CA trust models, can be regarded as special flavors of the networked trust model. They are both built on cross-certified CA trust relationships. Both the meshed and bridge CA trust models are supported in Windows Server 2003 PKI.

Meshed trust model

In a meshed trust model, every CA has a cross-certified trust relationship with every other CA in the trust model. This model is also known as the web of trust.

In both the networked and the meshed trust model, trust transitivity may lead to unexpected and unwanted trust relationships. Imagine that in the example in Figure 14.7 the HP CA sets up a cross-certification trust with a CA from Sun. Through trust transitivity Microsoft may suddenly end up with a PKI trust relationship with Sun. This problem is sometimes referred to as the “trust cascade.” To deal with this problem, you can set up constrained trust relationships. These are explained in Section 14.4.5.

Figure 14.7: Meshed trust model.

Bridge trust model

In a bridge CA or hub-and-spoke trust model- all cross-certification trust relationships are centralized at a central CA, called the bridge CA. Every other CA will have a cross-certified trust relationship with the bridge CA. The bridge CA acts a sort of trust facilitator between different trust domains or organizations. Contrary to the meshed trust model, every trust domain does not need to set up a two-way cross-certification trust relationship with every other trust domain. Also contrary to the meshed trust model, a bridge CA trust model allows for centralized trust transitivity control. We will come back to this when we discuss constrained trust relationships.

Figure 14.8: Bridge CA trust model.

14.4.4 Hybrid trust model

In a hybrid trust model, multiple trust models are combined into a single trust model. The example in Figure 14.9 combines a networked trust model with a hierarchical trust model. The dynamic nature of modern business relationships makes it very probable that this will be the PKI trust model of the future.

Figure 14.9: Hybrid trust model.

14.4.5 Constrained trust models

One of the major changes in Windows Server 2003 PKI is the built-in support for constrained trust models, or “qualified subordination” as Microsoft calls it. Qualified subordination allows the CA administrator to put constraints on the trust relationship that is set up with a subordinate CA (in a hierarchical trust model) or a peer CA (in a networked trust model). This ability to qualify trust aligns PKI trust closer to real-life trust: In reality it happens only occasionally that the trust is complete and not subject to certain conditions. It is a common misunderstanding that Windows Server 2003 qualified subordination only applies to cross-certified PKI trust relationships: It is available in both hierarchical and networked trust models.

The trust constraints used in qualified subordination are defined using certificate extensions embedded in a subordinate CA’s or a peer cross-certified CA’s certificate. Windows Server 2003 PKI supports the following trust constraint-related certificate extensions: basic constraints, name constraints, application policies, certificate policies, policy constraints, policy mappings, application policy constraints, and application policy mappings. Table 14.1 gives an overview of the constraint types.

Table 14.1: Certificate Constraint Extensions

Constraint Type	Used in Which Certificates?	Supported by PKI Clients?	Supported by CA Software?	Certificate Extension Used by Microsoft
Basic Constraints	CA and end-entity certificates	Windows 2000, Windows XP, Windows Server 2003	Windows 2000, Windows Server 2003	Basic Constraints
Name Constraints	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Name Constraints
Application Policies	CA and end-entity certificates	Windows XP, Windows Server 2003	Windows Server 2003	Application Policies
Issuance Policies	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Certificate Policies
Application Policy Mappings	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Application Policy Mapping
Application Policy Constraints	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Application Policy Constraints
Issuance Policy Mappings	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Policy Mapping
Issuance Policy Constraints	CA certificates	Windows XP, Windows Server 2003	Windows Server 2003	Policy Constraints

The name and policy constraints, policy mappings, application policy constraints, application policy mappings, and certificate policies extensions can only be added to CA certificates. Basic constraints and application policies can also be added to end-entity (user) certificates. Basic constraint extensions can be interpreted by Windows 2000, Windows Server 2003, and Windows XP PKI clients. The name, application policies, certificate policies, policy constraints, policy mappings, application policy constraints, and application policy mappings extensions can only be interpreted by Windows Server 2003 and Windows XP PKI clients. Likewise, a Windows 2000 CA only understands the basic constraint extensions; a Windows Server 2003 CA can deal with all of them. Figure 14.10 shows a certificate for a subordinate CA holding all eight new extensions as it is displayed in the Windows Server 2003 and XP certificate viewer.

Figure 14.10: The new constraint extensions in the certificate viewer.

More information about the certificate constraint extensions can be found in RFC 3280 (which replaces RFC 2459). With the exception of the following, Microsoft’s use of the extensions is relatively in line with the content of RFC 3280. To store application policies, Microsoft uses the application policies extension, which is not defined in RFC 3280—the latter recommends using the certificate policies extension for this purpose. The same is true for the application policy mappings and application policy constraints extension—RFC 3280 recommends storing the first one in the policy mappings extension and the second one in the policy constraints extension.

Basic Constraints

Basic Constraints is a certificate extension that can contain a field called “pathLenConstraint” (or path length constraint in readable format). It can only be used if the Basic Constraints “ca” field is set to true—which is only the case for a CA certificate. It gives the maximum number of nonselfissued CA certificates that may follow a certificate in a certification path and can be used to limit the length of the certificate chain.

In the hierarchical trust example in Figure 14.11 (Config 1), the administrator put a basic constraint in a subordinate CA’s certificate that limits the path length to 1. As a consequence, the CA that is located one level below that CA will not be able to issue another CA certificate but only end-user certificates. We will obtain the same result when we add a path length constraint of 2 to the root CA’s certificate (which is illustrated in Config 2 in Figure14.11). In that case the PKI software will automatically add a path length constraint of 1 to all subordinate CA certificates issued by the root CA.

Figure 14.11: Basic constraints—Path Length Constraint example.

The Path Length Constraint provides a solution to the trust cascade problem discussed earlier. It basically provides a trust “hop count.” The earlier example shows how the number of trust hops can be limited in a hierarchical PKI trust model. A Path Length Constraint can also be useful in a peer-to-peer cross-certification-based trust model. For example, in the bridge CA trust model, if the bridge CA wants to make sure that CAs cannot cross-certify with other CAs, he or she can issue them a certificate that contains a Path Length Constraint that is set to 0.

Name Constraints

A Name Constraint certificate extension can only be set in a CA certificate. It allows you to restrict the population to which a subordinate or cross-certified CA can issue certificates. You can use it to indicate a namespace within which the subject names and subject alternate names in a certificate request, or the IP addresses from which the certificate requests that were sent to a CA were issued must be located. It is kept in a CA certificate’s “Name Constraints” extension. Table 14.2 gives an overview of the Name Constraint types supported by Windows Server 2003 PKI and also lists the standards defining the different name formats.

Table 14.2: Name Constraint Types and Their Meaning

Name Constraint Type	Meaning
DNS Names (RFC 1034 and 1035–based)	Allows you to restrict certificate issuance based on the DNS name mentioned in the certificate request.
X.500 Distinguished Names (DNs) (X.500-based)	Allows you to restrict certificate issuance based on the DN mentioned in the certificate request. Can be used to issue certificates to a limited amount of users or computer objects in Active Directory.
Uniform Resource Identifiers (URIs) (RFC 2396–based)	Allows you to restrict certificate issuance based on the URI mentioned in the certificate request. Can be used to limit the issuance of SSL Web server certificates.
E-mail and User Principal Name (UPN) (RFC 822–based)	Allows you to restrict certificate issuance based on the email address or UPN mentioned in the certificate request.
IP address (RFC 791 or RFC 2460–based)	Allows you to restrict certificate issuance based on the IP address of the machine from which the certificate request was sent.

Following RFC 3280, a certificate name constraint extension indicates 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 further reduce the namespace rule it received from its parent CA; it can never extend it. For example, if a subordinate CA is permitted to issue certificates for users in the research.hp.com DNS domain, it can never issue a subordinate CA certificate that permits to issue certificates for users in the hp.com DNS domain.

In the hierarchical trust example in Figure 14.12, you can notice 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, the root CA administrator put a name constraint in subordinate CA 1’s certificate that excludes the UPN “@ibm.com” and permits the DNS names “.hp.com” and “.compaq.com.” When a certificate request comes in for “[e-mail],” it will be rejected. If a request comes in for “webserver1.hp.com,” it will be accepted. Subordi- nate CA 2’s namespace is even more restricted: It can only issue certificates in the .compaq.com DNS namespace. As a consequence, when a request for webserver2.hp.com comes in, it will be rejected. If a request comes in for mail.compaq.com, it will be accepted.

Figure 14.12: Name Constraints example.

Issuance policies

An issuance policy defines the conditions that were met when the certificate was issued. In a Windows Server 2003 certificate, an issuance policy is identified using its corresponding Object Identifier (OID) and is kept in a certificate’s “Certificate Policies” extension.

When they are added to a CA certificate, they define the set of issuance policies that will be included in any certificate (CA or end entity) issued by that CA. By including them in the cross-certification CA certificate, you can use them to limit the trust you have in the certificates issued by a cross- certified CA. In this context the enforcement of the extension is up to the certificate chain validation logic. The latter logic is only available in Windows XP and Windows Server 2003.

When issuance policies are included in an end-entity certificate, enforcement of the policies must be done on the level of the PKI-enabled application. It must check whether it permits a certificate issued under a certain issuance policy or not. This means that the application must be intelligent enough to know which issuance policies it supports.

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

Table 14.3: Predefined Windows Server 2003 PKI Issuance Policies and their Meaning

Issuance Policy Type	Meaning
All Issuance OID: 2.5.29.32.0	Issuance policy containing all other issuance policies. This type is only used for CA certificates.
Low Assurance OID: 1.3.6.1.4.1.311.21.8. a.b.c.d. 1.400	Certificates issued with no additional security requirements.
Medium Assurance OID: 1.3.6.1.4.1.311.21.8. a.b.c.d. 1.401	Certificates issued with additional security requirements. A good example of such requirements is a smart card certificate requiring a face-to-face issuance process.
High Assurance OID: 1.3.6.1.4.1.311.21.8. a.b.c.d. 1.402	Certificates issued with the utmost security requirements. A good example of such requirements is the issuance of a key recovery agent certificate that may require additional security background checks as part of the issuance process.

Figure 14.13 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, it will be rejected. It can only be used in PKI-enabled applications requiring a low assurance issuance policy.

Figure 14.13: Issuance policy example.

Application policies

An application policy limits the applications for which a certificate can be used. It can be set in both CA (hierarchical and cross-certified) and end- entity certificates. As for issuance policies, application policies are identified using the OID of the corresponding policy. They are kept in a certificate’s “Application Policies” extension. Table 14.4 shows the predefined application policies of Windows Server 2003 PKI and their corresponding OIDs.

Table 14.4: Predefined Application Policy Constraints and Corresponding OIDs

Application Policy Name	Corresponding OID
All Application Policies	1.3.6.1.4.1.311.10.12.1
Certificate Request Agent	1.3.6.1.4.1.311.20.2.1
Client Authentication	1.3.6.1.5.5.7.3.2
Code Signing	1.3.6.1.5.5.7.3.3
Digital Rights	1.3.6.1.4.1.311.10.5.1
Directory Service E-mail Replication	1.3.6.1.4.1.311.21.19
Document Signing	1.3.6.1.4.1.311.10.3.12
Embedded Windows System Component Verification	1.3.6.1.4.1.311.10.3.8
Encrypting File System	1.3.6.1.4.1.311.10.3.4
File Recovery	1.3.6.1.4.1.311.10.3.4.1
IP Security End System	1.3.6.1.5.5.7.3.5
IP Security IKE Intermediate	1.3.6.1.5.5.8.2.2
IP Security Tunnel Termination	1.3.6.1.5.5.7.3.6
IP Security User	1.3.6.1.5.5.7.3.7
Key Pack Licenses	1.3.6.1.4.1.311.10.6.1
Key Recovery	1.3.6.1.4.1.311.10.3.11
Key Recovery Agent	1.3.6.1.4.1.311.21.6
License Server Verification	1.3.6.1.4.1.311.10.6.2
Lifetime Signing	1.3.6.1.4.1.311.10.3.13
Microsoft Time Stamping	1.3.6.1.4.1.311.10.3.2
Microsoft Trust List Signing	1.3.6.1.4.1.311.10.3.1
OEM Windows System Component Verification	1.3.6.1.4.1.311.10.3.7
Private Key Archival	1.3.6.1.4.1.311.21.5
Qualified Subordination	1.3.6.1.4.1.311.10.3.10
Root List Signer	1.3.6.1.4.1.311.10.3.9
Secure Email	1.3.6.1.5.5.7.3.4
Server Authentication	1.3.6.1.5.5.7.3.1
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Time Stamping	1.3.6.1.5.5.7.3.8
Windows Hardware Driver Verification	1.3.6.1.4.1.311.10.3.5
Windows System Component Verification	1.3.6.1.4.1.311.10.3.6

In version 2 certificates^[1] generated by Windows Server 2003 CAs, application policies have exactly the same function as the Extended Key Usage (EKU) certificate extension. For downlevel compatibility, Windows Server 2003 CAs and Windows Server 2003 and XP clients can still deal with the EKU extension. Microsoft has chosen to use the application policies extension instead of the EKU extension because application policies can be mapped and restricted using the application policy mappings and application policy constraints certificate extensions.

Application policies can be set in both end-entity and CA certificates. If it is set in an end-entity certificate, it limits the applications for which the certificate can be used. If it is set in a CA certificate, it will be copied in all certificates (end-entity and CA) the CA issues and thus limit the applications for which those certificates can be used. In this case it will also limit the certificate types that a CA can issue. For an enterprise CA, the application policy settings even overrule the certificate templates that have been loaded in its certificate templates container. For example, if you want a subordinate CA to issue only user certificates, you need to make sure that you add the application policy OIDs for the Encrypting File System, Secure E- mail as well as 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 that has 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 do this validation is only available in Windows XP and Windows Server 2003.

Figure 14.14 shows the effect of setting application policies in CA certificates. In the figure an application policy has been set in the certificates of the subordinate CAs 1 and 2. Subordinate CA 1 will accept both e-mail and SSL certificate requests. Subordinate CA 2 can only issue e-mail certificates. It will reject SSL certificate requests.

Figure 14.14: Application policy example.

Policy Mappings and Policy Constraints extension

In this section we explain two other trust constraint-related certificate extensions that are supported by Windows Server 2003 PKI: the Policy Mappings, Policy Constraints, Application Policy Mappings, and Application Policy Constraints extensions. The first two apply to issuance policies and the latter two to application policies. Only the first two extensions are defined in RFC 3280.

Figure 14.15: Issuance policy mapping for cross-certified CAs example.

When defining issuance and application policies in a cross-certified CA trust relationship, policy mappings must be set up between the two cross- certified CAs because the policy OID used in one CA’s trust domain cannot be understood by the users of the other CA’s trust domain. In the example in Figure 14.15, a policy mapping has been defined between the issuance policies of two cross-certified CAs. CA2’s cross-certificate contains a map- ping between the CA1 issuance policy and its proper issuance policy. CA1’s cross-certificate contains a mapping between the CA2 issuance policy and its proper issuance policy.

Figure 14.16 shows the effect of defining policy mappings in a cross-certificate on the certificates trusted by a user. User 1 in the example trusts CA1. CA1 has issued a cross-certificate for CA2 containing policy mappings between its proper issuance policy called SmartCardOnly and the issuance policy of CA2 called HighSecureIssuance. When no policy mappings were defined in CA2’s cross-certificate, user 1 would not trust the certificate of user 2—because it contains an unknown issuance policy. Thanks to the inclusion of a policy mapping in the cross-certificate, user 1 will trust user 2’s certificate.

Figure 14.16: Issuance policy mapping PKI user example.

The Policy Constraints extensions allow you to specify how an issuance or application policy constraint that has been defined in the certificate of a particular CA will affect the validity of the certificate chain of a certificate containing that CA certificate. In other words, it specifies how an issuance or application policy constraint that has been defined in the certificate of a particular CA affects the validity of the CA certificates that are subordinate to that CA. The latter CAs can be subordinate CAs (in a hierarchy) or cross-certified CAs (in a networked trust model).

Two types of policy constraints can be defined:

• Require explicit policy: This constraint specifies a number that indicates the number of layers below the CA that has the constraint in its certificate where the issuance or application policy must be defined in the subordinate CA certificate. If the application policy is not defined in the subordinate CA certificates, the certificate that has these CA certificates in its chain will be rejected.

  Figure 14.17 shows the effect of setting the Require explicit policy extension to 1 in a subordinate CA’s certificate. The end entity’s certificate in config 1 will be invalid because the subordinate CA that’s located one level below the level 1 subordinate CA does not have the “HPpolicy” policy defined in its certificate. In config 2 the end entity’s certificate will be valid because the subordinate CA at level 2 does have the “HPpolicy” policy defined.

  
  Figure 14.17: Require explicit policy Policy Constraint example.

• Inhibit policy mapping: This constraint specifies a number that indicates the number of layers below the CA that has the constraint in its certificate where policy mappings can be defined in the subordinate CA certificate. This means that at levels below the specified number, policy mappings will be ignored. This setting protects against unexpected trust relationships as a consequence of policy mappings.

Figure 14.18 shows the effect of setting the Inhibit policy mapping extension to 1 in a cross-certification certificate: The user will not trust the cross-certificate issued by CA3 for CA2. If the extension was set to 2, the user would trust the latter certificate. Setting Inhibit policy mapping to 1 limits the number of layers where policy mappings can be defined to 1. Although the cross-certificate issued by CA3 for CA2 contains a valid mapping, it is two layers away from the certificate where the Inhibit policy mapping restriction is set. This example shows how the Inhibit policy mapping extension can be used to deal with the trust cascade problem that was mentioned earlier in this chapter.

Figure 14.18: Inhibit policy mapping Policy Constraint example.

14.4.6 Which trust model for which environment?

Table 14.5 provides an overview of the trust models that are typically chosen for a particular environment. Table 14.5 does not provide the ultimate overview of which trust model to choose for which environment. Your organization may have valid reasons to choose a completely different trust model than the one shown in the table. Choosing a trust model is a complex problem involving many different factors.

Table 14.5: Which Trust Model for Which Environment: Overview

Environment	Trust Model
Within a Single Organization (Outsourced PKI)	Hierarchical Model
Within a Single Organization (Insourced PKI) Small Organization Medium Organization Large Organization	Hierarchical Model Hierarchical Model (one level) Hierarchical Model (two levels), possibly with constrained trust (Qualified Subordination) Hierarchical Model (three levels), possibly with constrained trust (Qualified Subordination)
Between Organizations	Networked Model (including meshed and bridge CA trust models), possibly with constrained trust (Qualified Subordination) Hybrid Model, possibly with constrained trust (Qualified

^[1]Version 2 certificates are certificates that are generated by an Enterprise CA based on a version 2 certificate template.