Export (0) Print
Expand All

Qualified Subordination Deployment Scenarios

Updated: August 13, 2009

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.

noteNote
This section looks at the design process of qualified subordination. The Walkthrough section provides the actual deployment steps involved when defining qualified subordination between two CA hierarchies.

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.

Art Image

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.

Art Image

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.

noteNote
Alternatively, as mentioned earlier when defining the types of constraints, the AsiaCA can obtain a subordinate CA certificate from the RegionCA that includes the defined name constraints. Either method would provide the necessary name constraints to issued certificates.

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

Art Image

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.

noteNote
For more information about how to perform the qualified subordination, see the Walkthrough section.

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.

ImportantImportant
Cross-certification of a CA hierarchy may create very long certificate chains that can increase the size of network traffic for IPSEC, Secure Mail (s/mime), SSL, and so on. Use caution so as to not increase the chain length and overall certificate chain byte size to exceed an application limit.

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.

Art Image

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.

Art Image

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:

Art Image

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

Art Image

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:

Art Image

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:

noteNote
In all cross-certification designs, a single certificate will chain to different roots depending on which organization's computers are validating the certificate. In both examples, a certificate validated by computers at Contoso Consulting will chain to the PartnerCA root, while certificates validated by computers at Northwind Traders will chain to the CorpCA root.

Art Image

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.

Art Image

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.

Art Image

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

bcddf54b-fa9c-480b-8ca6-9ce136024777

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.

4273326f-df20-4b0d-bde5-59dfab9b2602

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.

3a0e7094-6ab3-4100-9087-969f0ff134c3

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

e62c36a8-803b-4d65-9062-31e2b92e6633

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:

37cbe7d6-63db-4745-9f8e-98c865a516ca

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

85a7f261-ac72-4aaa-baa9-ef519f01ea02
noteNote
In all cross-certification designs, a single certificate will chain to different roots depending on which organization's computers are validating the certificate. In both examples, a certificate validated by computers at Contoso Consulting will chain to the PartnerCA root, while certificates validated by computers at Northwind Traders will chain to the CorpCA root.

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.

1af9b1e6-ed25-4cce-98bf-855387b0467a

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.

d396255a-e8d1-4cf9-ae37-87e8b171abfd

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

c6bb4b90-850b-43e2-8c49-a9a82dea7b36

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.

15806c9a-0d13-4c63-b061-24465bc3659f

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:

6c52512e-f2a7-4dc3-a698-6f7b55f2817c

The certificate issued to user2 will chain as follows:

f7f5e0e5-87b0-4400-8efc-f33cd522ed28

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:

0e67023d-bc26-49fc-8729-7174daff5bd7

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

8588bba4-d8fd-494e-8124-6db60c159ff9

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.

632cec3d-9b63-440d-9528-b9134d7f8670

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.

879ef6a2-2796-4add-ab92-16acd4e55a7f

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.

6780c57c-99ec-4996-b94a-0e026d96b9a6

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.

    noteNote
    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.

    noteNote
    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.

    noteNote
    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.

    ImportantImportant
    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.

ImportantImportant
Even if a BridgeCA is implemented, there is still nothing preventing two organizations participating in the Bridge CA structure from using qualified subordination to define a separate relationship between their hierarchies. For example, while Secure Mail certificates may be validated through the Bridge CA for e-mail sent between Northwind Traders and Contoso Consulting, a separate qualified subordination may be established between CAs in the two organizations to define specific policy constraints that must exist in certificates for signing purchase orders for transactions greater than 1 million dollars between the two organizations. Depending on the certificates attributes, the validation process will select the appropriate certificate chain based on the certificates usage and the defined qualified subordinations between the two organizations.

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

e765707e-55c5-4e91-b265-853d6ba39e8d

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.

noteNote
Alternatively, the cross-certification can be performed between the root CA of each organization and the BridgeCA. Again, the decision will be based on the security policy of each organization using the bridge CA, whether the organizations are willing to issue a cross-certification certificate from their root CA to the bridge CA, and the CRL publication period of the root CAs.

ImportantImportant
Cross-certification of a CA hierarchy may create very long certificate chains that can increase the size of network traffic for IPSEC, Secure Mail (s/mime), SSL, and so on. Use caution so as not to increase the chain length and overall certificate chain byte size to exceed an application limit.

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:

4a55caff-b413-4970-8e65-231e94527f53

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

36b22a74-36d9-4d79-a07a-13f5e9073aac

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:

fba018c6-9ab0-46d3-b496-a9971ee40e0f

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.

608d10ce-7282-4e82-a354-e3db0afd4bb6

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.

feb7cfb1-4e35-4131-a50d-4419c3d7ffce

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

3f814521-ed38-4d80-ad2c-74609ffea6d2

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

77e126d2-5ed5-472f-b727-2757cc6b85f8

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.

noteNote
Additional name constraints could be defined for NameConstraintsPermitted to restrict what specific namespaces are allowed into the organization through the BridgeCA.

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.

bd86c322-5005-49f7-b5d0-b839b26608f1

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.

noteNote
Remember that these application policies also are combined with name constraints and policy constraints when applied to a certificate presented from another CA hierarchy. If you require different combinations, you must request multiple cross-certification authority certificates using separate Policy.inf files for each request. For example, you may not wish to implement policy constraints for e-mail certificates, but want to ensure that low or medium assurance object identifiers exist in client and server authentication certificates. This would require two separate cross-certification authority certificate requests—one for Secure E-mail and one for Client and Server Authentication.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft