Qualified Subordination Deployment Scenarios

Applies To: Windows Server 2003 with SP1

This section looks at some of the more common certificate services deployments that use qualified subordination, including the following scenarios:

• Using qualified subordination to restrict certificate issuance to specific namespaces

• Configuring qualified subordination between two organizations; specifically two configurations:

  • Allowing trust between all CAs in the two organizations

  • Limiting trust to specific CAs in the CA hierarchy

• Configuring qualified subordination using a bridge CA

This section covers both the design of the scenarios and how to deploy the scenarios.

Restricting Namespaces

The first example is a common scenario in large organizations where certificate services administration is decentralized. In a decentralized environment, it may be desired to restrict certificate issuance to only specific objects in Active Directory. Use of name constraints is an effective way to ensure specific CAs can only issue to a well-defined subset of users framed by a namespace.

Assume that Contoso uses the forest structure in Figure 4 to provide decentralization of administration to regional subsidiaries.

Figure 4: Contoso.coms Forest and Domain Structure

Within Contoso.com, several CAs have been deployed for certificate services deployments. Figure 5 shows the current CA hierarchy used by Contoso.com.

Figure 5: A Proposed CA Hierarchy for Contoso Corporation

In this example, the CA named RegionCA exists to allow decentralized management of certificate deployment for Europe and Asia. The EuropeCA and AsiaCA are installed on member servers in the europe.contoso.com and asia.contoso.com domains. Qualified subordination can be used to restrict the issuance of certificates by the AsiaCA to only security principals (users, computers, services) located in the asia.contoso.com domain.

To do this, the AsiaCA must be installed with a CAPolicy.inf file in the %SystemRoot% folder with the following settings:

[NameConstraintsExtension]
Include = NameConstraintsPermitted
Exclude = NameConstraintsExcluded
Critical = True

[NameConstraintsPermitted]
DNS = .asia.contoso.com
email = @asia. contoso.com
UPN = .asia.contoso.com
UPN = @asia.contoso.com
DIRECTORYNAME = "DC=asia,DC=contoso,DC=com

[NameConstraintsExcluded]

These name constraints will only allow security principals from the asia.contoso.com domain to receive certificates issued by the AsiaCA certification authority. If a request is received from a security principal from a different namespace, the certificate request will be denied due to the configured name constraints.

For example, Figure 6 shows the name constraints in place for AsiaCA restricting certificate issuance to the asia.contoso.com namespace.

Figure 6: Applying Name Constraints at AsiaCA

In this example, the certificate request by user3@asia.contoso.com is approved because Noels UPN is included in the permitted name constraints. In comparison, the request by user5@europe.contoso.com is denied because the UPN Europe.contoso.com is not listed in the permitted name constraints and is considered to be an excluded name constraint.

Enterprise CAs enforce name constraints during certificate requests based on the authenticated security principal performing the certificate request. The credentials of the security principal are used to extract the names of the user from Active Directory and these names are compared with the defined name constraints. In this case, user3 would be logged on to the network and performing the successful certificate request.

Creating Trust Between Two Organizations

The second scenario where cross-certification may be used is to allow certificates to be used and trusted between two organizations. Before the cross-certification is performed between the two organizations, the first thing that must be decided is what certificate usage will be trusted between the organizations. For example, you could require that certificates be trusted from the other organization(s) only for secure e-mail. Or, you could allow secure e-mail, client authentication, and server authentication.

This must be decided and included in the Policy.inf file when the qualified subordination is configured between CAs in the two organizations.

When configuring the cross-certification between the two organizations, you also must decide whether all CAs in the other organizations CA hierarchy are to be trusted or only a specific grouping of CAs in the hierarchy.

Implementing Qualified Subordination to Trust All CAs

In the first example, qualified subordination will be configured so that all CAs in the two organizations are trusted by the other organization. Figure 7 shows the two CA hierarchies.

Figure 7: Two Non-Connected CA Hierarchies

In this scenario, there is a business need for user 1 and user 2 to exchange secure e-mail using Outlook and S/MIME. Due to increased cooperation between Northwind Traders and Contoso Consulting, it is decided that qualified subordination be used to permit secure e-mail certificates issued by either organization to be trusted by both Northwind Traders and Contoso Consulting. In addition, the secure e-mail certificates can be issued by any CA in the individual CA hierarchies.

To accomplish this, two different methods can be used:

• Cross-certification between root Cas

  In this design, the root CAs issue cross-certification certificates to the other hierarchy's root CA. This is the easiest method to cross-certify organizations and is the easiest to understand when troubleshooting qualified subordination problems.

• Cross-certification between subordinate and Root Cas

  Many organizations are unwilling to issue certificates from their root CA to other organization's root CA. In this case, the cross-certification certificates can be issued by a subordinate CA to the root CA in the partner organization's CA hierarchy.

Both methods allow for complete trust between the CA hierarchies, subject to the constraints defined in the Policy.inf files. The decision factors will be based on whether your organization is willing to issue a cross-certification certificate to a partner organization's root CA from your root CA. Another consideration is that Root CAs generally publish their CRL less frequently than subordinate CAs. If there is a possibility that the cross-certification authority certificate may be revoked, it is preferable to issue the certificate from a subordinate CA than from a root CA. A certificate issued from a subordinate CA will have less lag time between the time the certificate is revoked and the revocation being recognized by all clients.

Cross-Certification Between Root CAs

If your organization is willing to perform cross-certification between the root CAs, the configuration in Figure 8 can be used.

Figure 8: Configuring Complete Trust Between Root CAs

In this example, the root CA for each organization is cross-certified with the root CA in the other organization. To create this configuration, the qualified subordination must be performed twice:

1. The PartnerCA at Contoso Consulting must be cross-certified using qualified subordination with the CorpCA at Northwind Traders.

2. The CorpCA at Northwind Traders must be cross-certified using qualified subordination with the PartnerCA at Contoso Consulting.

The qualified subordination will require that the following be in place:

• A Policy.inf is configured at each root CA. The Policy.inf must define any name constraints, issuance constraints, and application constraints defined between the two organizations and is used during the cross-CA certificate request as described in the Walkthrough section.

• The user account that is performing the qualified subordination must obtain a certificate with the Qualified Subordination application policy object identifier to sign the qualified subordination request between the two organizations. The signing certificate must be obtained from the CorpCA or any CA that is trusted on the CorpCA and PartnerCA computers for the first request and from the PartnerCA or any CA that is trusted on the CorpCA and PartnerCA computers for the second request.

The configuration shown in Figure 8 allows certificates issued by either CA to chain to a root that is trusted by each respective organization. For example, the certificate issued to User1 will validate up to the CorpCA if verified by a security principal at Northwind Traders as follows:

If the same certificate is validated by a computer in the Contoso Consulting organization, the certificate will validate up to PartnerCA.

Similarly, the certificate issued to User2 will chain to a trusted root in each organization. If the certificate is validated by a computer at Northwind Traders, the certificate chain will be as follows:

However, the same certificate would validate differently and use the PartnerCA root CA as the trust anchor when validated by a computer in the Contoso Consulting organization:

The advantage of this design is that it also allows trust of new CAs installed into the CA hierarchies at either organization. For example, Figure 9 shows the addition of a new CA at Northwind Traders.

Figure 9: Adding an Additional CA to the Hierarchy

In this case, the certificate issued to User4 is trusted in both organizations. In Northwind Traders, the certificate chains to the CorpCA root CA.

While at Contoso Consulting, the certificate chains to the trusted PartnerCA.

Cross-Certification Between Subordinate and Root CAs

The same level of trust can be established between two organizations by issuing the cross-certification authority certificate from a subordinate CA in your CA hierarchy. This strategy is recommended if your organization's security policy prohibits the issuance of crossCA certificates by the root CA, your organization is simply unwilling to issue cross-certification certificates at the root CA, or there is a possibility that the cross-certification authority certificate may be revoked, and the CRL publication period for the root CA is a long interval. In these cases, the configuration shown in Figure 10 can be used to create complete trust between the two CA hierarchies, subject to defined qualified subordination constraints.

Figure 10: Configuring Complete Trust Between Subordinate and Root CAs

In this example, the Root CA for each organization is cross-certified with the subordinate enterprise CA in the other organization. To create this configuration, the qualified subordination must be performed twice:

1. The PartnerCA at Contoso Consulting must be cross-certified using qualified subordination with the IssuingCA at Northwind Traders.

2. The CorpCA at Northwind Traders must be cross-certified using qualified subordination with the PolicyCA at Contoso Consulting.

The qualified subordination will require that the following be in place:

• A Policy.inf is configured at each subordinate CA. The Policy.inf must define any name constraints, issuance constraints, and application constraints defined between the two organizations and is used during the cross-CA certificate request as described in the Walkthrough section.

• The user account that is performing the qualified subordination must obtain a certificate with the Qualified Subordination application policy OBJECT IDENTIFIER to sign the qualified subordination request between the two organizations. The signing certificate must be obtained from the IssuingCA or any CA that is trusted on the CorpCA and PartnerCA computers for the first request and from the PolicyCA or any CA that is trusted on the CorpCA and PartnerCA computers for the second request.

The following configuration allows certificates issued by either CA to chain to a root that is trusted by each respective organization. For example, the certificate issued to User1 will validate up to the CorpCA if verified by a security principal at Northwind Traders.

If the same certificate is validated by a computer in the Contoso Consulting organization, the certificate will validate up to PartnerCA.

Similarly, the certificate issued to User2 will chain to a trusted root in each organization. If the certificate is validated by a computer at Northwind Traders, the certificate chain will be as follows:

While, the same certificate would validate up to the PartnerCA root CA when validated by a computer in the Contoso Consulting organization.

As with the model where the cross-certification is established between root CAs, this design also allows trust of new CAs installed into the CA hierarchies at either organization. Figure 11 shows the addition of a new CA at Northwind Traders.

Figure 11: Adding an Additional CA to the Hierarchy

In this case, the certificate issued to User4 is trusted in both organizations. In Northwind Traders, the certificate chains to the CorpCA root CA.

While at Contoso Consulting, the certificate chains to the trusted PartnerCA.

Implementing Qualified Subordination to Limit Trust to Specific CAs

In some situations, two organizations may wish to restrict the cross-certification to specific CAs or to specific portions of the CA hierarchy, for example, where an organization uses outside consulting services. The organization (Northwind Traders) and consulting firm (Contoso) may wish to restrict the cross-certification to specific CAs in the hierarchy.

Figure 12 shows the scenario where the qualified subordination is performed to limit the trust between specific CAs in the organization.

Figure 12: Configuring a Limited Trust Relationship

With this configuration, the certificates issued by the IssuingCA and the PolicyCA will validate up to a trusted root CA in both organizations.

At Northwind Traders, the certificate issued to user1 will chain as follows:

The certificate issued to user2 will chain as follows:

At Contoso Consulting, the certificates will chain with the PartnerCA being the trusted Root CA. For the user1 certificate, the following chain will be selected by a validation process:

For the user2 certificate, the validation process will also select the chain that chains to the PartnerCA root CA.

The major difference between this qualified subordination design and the design that allowed total trust between CAs in the two hierarchies is best shown by investigating an additional CA added to the Northwind Traders CA hierarchy as shown in Figure 13.

Figure 13: Adding an Additional CA to the Hierarchy

In this case, the ProjectCA was added to the Northwind Traders CA hierarchy. To a computer in the Northwind Traders network, the certificate issued to user4 is valid because it chains to a trusted root CA, the CorpCA.

When a computer from the Contoso Consulting organization is presented the user4 certificate, only a partial chain can be built and the chain does not terminate at a trusted root certificate.

Types of Constraints

Qualified subordination allows constraints to be applied to a cross-certification configuration. Rather than implicitly trusting all certificates issued by another organizations CA hierarchy, qualified subordination allows you to define application, naming, and issuance constraints.

For example, when qualified subordination is established between two organizations, some of the constraints they may wish to configure include:

• Application policy Rather than allowing all certificates to be trusted, specific application purposes can be defined for the issued crossCA certificate by defining what object identifiers are required in certificates from the other organization. For example, if an organization wishes to only accept S/MIME certificates from a partner organization, an application policy can be defined to only accept certificates with the Secure E-mail object identifier (1.3.6.1.5.5.7.3.4) in the application policy extension or in the EKU extension.

  Note

  Enhanced Key Usage is defined in part 4.2.1.13 in RFC 2459.

• Name Constraints Whenever qualified subordination is used between two organizations, the organization issuing the CrossCA certificate should include a name constraint that excludes its namespace through the cross-certification. This prevents the partner organization from submitting a certificate using the other organizations namespace. For example, Northwind Traders would implement a name constraint that prevents Contoso from presenting certificates that are issued to a user from Northwind Traders. In other words, if a CA in the Contoso hierarchy issued a certificate with a subject name of user1@northwindtraders.com, the name constraint would exclude the nortwindtraders.com e-mail address and would invalidate the certificate.

  Note

  Name Constraints are defined in part 4.2.1.11 in RFC 2459.

• Policy Constraints To ensure a level of trust for partner certificates, policy constraints (sometimes referred to as issuance policy) can be defined and must be included as attributes of presented certificates to be accepted by the partner organization. For example, if two partner organizations are involved in a buyer/seller relationship, a Million Dollar object ID can be defined. For purchases of 1,000,000 USD or more, the signing certificate must contain the Million Dollar object identifier. Because the object identifier must be defined in both organizations, the Policy.inf file must map the object identifier from one organization to the other organizations object identifier. Likewise, constraints can be applied to whether the object identifier can be mapped to other object identifiers, or whether the object identifier must be issued from a specific CA or limit how many layers below the cross-certified CA can issue a certificate containing the object identifier.

  Note

  Policy Constraints is defined in part 4.2.1.5 in RFC 2459 and are referred to as the Certificate Policies extension in the RFC.

  Important

  If different combinations of policy and name constraints are required for application policies, you may have to perform the qualified subordination multiple times. For example, if you are willing to accept any Secure E-mail certificates, but will only accept High and Medium Assurance object identifiers for Client and Server authentication certificates, two separate Policy.inf files must be defined and the qualified subordination process must be executed twice—once for each Policy.inf file. This results in two separate Cross-Certification Authority certificates being issued—one for Secure E-mail certificates and one for Client and Server Authentication certificates. The cross-certification certificates are ultimately trusted for different purposes. Applications will verify the policy object identifiers when making authentication or authorization decisions.

Creating Trust Between Multiple Organizations

When you require trust between more than two, three, or more organizations, it is sometimes easier to design the qualified subordination by using a Bridge CA. The Bridge CA will act as a link between the CA hierarchies in each organization. Each organization will validate certificates issued by other organizations that use chains that include the Bridge CA. The Bridge CA design also reduces the complexity involved when new organizations are included in the trust.

A Bridge CA has several advantages over configuring separate trust relationships between multiple organizations, including

• A Bridge CA reduces the complexity for defining trust between CA hierarchies when three or more CA hierarchies exist.

• It is easier to add an additional organization to an existing Bridge CA trust relationship. The only tasks that must be performed are as follows:

  1. Issue the Bridge CA a cross-certification certificate using qualified subordination from each organization.

  2. Issue a cross-certification certificate from the Bridge CA for the root CA of the new organization.

  3. Publish the Bridge CA issued certificate in all other organizations to complete the web of trust created by the BridgeCA.

• The Bridge CA can offer a method to manage trust between subsidiary organizations by a holding company.

A common design for the Bridge CA deployment is shown in Figure 14.

Figure 14: Using a Bridge CA

In this design, total trust is established between all CAs in the three organizations, subject to any name, issuance, and application policies defined in the qualified subordination.

To achieve this, qualified subordination is defined so that the Bridge CA receives a subCA certificate defining all application, naming, and policy constraints from the subordinate enterprise CA in each organization. In addition, the root CA in each organization receives a subCA certificate defining all application, naming, and policy constraints from the Bridge CA.

Viewing Certificates from the Three Organizations

The result is complete trust between the organizations using the BridgeCA for the certificate purposes defined in the qualified subordination. As long as an issued certificate meets all defined application, name, and policy constraints, the certificate will be considered valid in any organization connected to the Bridge CA in this manner.

In this example, the user1 certificate would chain to the CorpCA trusted root for all computers at Northwind Traders as follows:

The user1 certificate would chain to the OrgCA trusted root for all computers at Fabrikam Inc. as follows:

If the same certificate is evaluated by the certificate chaining engine at a computer in the Contoso organization, the resulting certificate chain would be as follows:

Likewise, the certificates for user6 and user2 would chain to the trusted root for each of the three organizations, based on what organization the computer evaluating the certificate belongs to.

Adding New CAs to Existing CA Hierarchies

This design for Bridge CA deployment allows for the addition of new CAs to the hierarchies at any of the participating organizations, without having to modify the existing qualified subordination using the Bridge CA. For example, if the Project CA is added to the Northwind Traders CA hierarchy as shown in Figure 15, the certificate issued to user4 would be trusted by computers in the Northwind Traders, Fabrikam Inc., and Contoso Consulting organizations, subject to application, naming, and policy constraints.

Figure 15: Adding a New CA to the Northwind Traders CA Hierarchy

In this case, the user4 certificate would chain to the CorpCA trusted root for the computers in the Northwind Traders organization.

The certificate would chain to the OrgCA trusted root for the computers in the Fabrikam Inc. organization.

Finally, the certificate would chain to the PartnerCA trusted root for the computers in the Contoso Consulting organization.

Using Name Constraints with Bridge CAs

To prevent CAs in the other organization from creating certificates with subject names from your organizations namespace, name constraints should be created to exclude your namespace from certificates trusted through the BridgeCA.

For example, for the cross-certification authority certificate issued to BridgeCA from the CorpCA, the following name constraints could be added to the Policy.inf file at the CorpCA:

[NameConstraintsExtension]
Include = NameConstraintsPermitted
Exclude = NameConstraintsExcluded
Critical = TrUe

[NameConstraintsPermitted]
DNS = ""
email=""
UPN=""

 [NameConstraintsExcluded]
DNS = .northwindtraders.com
email = @northwindtraders.com
UPN = .northwindtraders.com
UPN = @northwindtraders.com
DIRECTORYNAME = "DC=Northwindtraders,DC=com"

These name constraints will ensure that all namespaces except the NorthwindTraders namespace will be permitted.

Policy Constraints and Policy Constraint Mapping

The qualified subordination between the organizations may also require specific policy constraints to exist for trusted certificates. If a specified policy constraint is not included in a certificate, the application should not select the chain including that certificate.

The problem with policy constraints is that for each CA hierarchy, the policy constraint may have a different name and it will have a different object identifier. To make the policy constraints interoperate between the CA hierarchies, the policy constraints must be defined and mapped in the Policy.inf file.

For example, if the BridgeCA will function to only allow Low and Medium Assurance certificates to be passed between the organizations, the policy constraints must be defined in each cross-certification certificate issued between CAs.

For the cross-certification authority certificate issued to CorpCA by the BridgeCA, the Policy.inf file must contain the following lines to define the medium and low assurance object identifiers. These object identifiers may be obtained from the Certificate Templates console or from the IANA:

[PolicyStatementExtension]
Policies = MediumAssurance, LowAssurance
CRITICAL = FALSE

[MediumAssurance]
OID = 1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.401

[LowAssurance]
OID = 1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.400

In addition to defining the object identifiers for its CA hierarchy, the Policy.inf file must also map the Medium and Low Assurance object identifiers to the object identifiers used at the BridgeCA. This is accomplished through the [PolicyMappingsExtension] section of the Policy.inf file:

[PolicyMappingsExtension]

1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.401 =
1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.1990074901.2398624335

1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.400 =
1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.572751058.2135922791

critical = yEs

This section maps the object identifier ID for medium assurance to an object ID defined at the BridgeCA. The object identifier does not have to be for the MediumAssurance policy constraint. In fact, it can be for a user-defined policy object identifier, as the previous example shows.

To complete the policy mappings, the following lines must be included in the Policy.inf file used by the BridgeCA to receive a cross-certification authority certificate from the IssuingCA:

[PolicyStatementExtension]
Policies = SecLevel1, SecLevel2
CRITICAL = FALSE

[SecLevel1]
OID =
1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.1990074901.239862
433

[SecLevel2]
OID =
1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.572751058.2135922
791

[PolicyMappingsExtension]
1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.1990074901.239862
433 = 1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.401

1.3.6.1.4.1.311.21.8.2812900009.1258984576.2698790533.44255976.572751058.2135922
791 = 1.3.6.1.4.1.311.21.8.1608391590.1259233725.355412102.3300744578.1.400

critical = yEs

As you can see, custom object identifiers were defined for the policies named SecLevel1 and SevLevel2. In the [PolicyMappingsExtension] section, the same object identifiers are mapped with the order reversed from the Policy.inf file used by the CorpCA to receive a cross-certification authority certificate from the BridgeCA.

Figure 16 shows another example of policy constraint mapping.

Figure 16: Policy Constraint Mapping

In this figure, the NorthwindCA is configured with a MillionDollar object identifier, 1.3.6.1.4.1.311.21.8.124. This object identifier is mapped to the BigOrder object identifier, 1.3.6.4.1.204.22.33.44, at the ContosoCA. Although the certificate issued to v-user1 contains a different issuance policy object identifier from the certificate issued to user2, the policy constraint mapping makes the object identifiers equivalent and the object identifiers are recognized by both CA hierarchies.

Application Policy

The final policy that could be applied in this scenario is the application policy. Application policy will limit which purposes certificates issued by another organizations CAs can be used for. By defining application policy, you can prevent certificates for specific usages from being accepted for use in your organization.

For example, if you only want to allow certificates for S/MIME, client authentication, and server authentication to be recognized through the BridgeCA, you can add the following sections to the Policy.inf file:

[ApplicationPolicyStatementExtension]
; list of user defined policies
Policies = AppOIDPolicy1, AppOIDPolicy2, AppOIDPolicy3

[AppOIDPolicy1]
OID = 1.3.6.1.5.5.7.3.4 ; Secure Email

[AppOIDPolicy2]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication

[AppOIDPolicy3]
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication

CRITICAL = FALSE

These application policies would prevent the use of an EFS certificate between the organizations. An EFS certificate would not chain in a trusted manner because the defined application policies define an application policy for EFS encryption services.