Mapping policies between trust hierarchies
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Mapping policies between trust hierarchies
To establish trust between users and computers in different trust hierarchies, you can map the issuance and application policies of each trust hierarchy. The qualified subordinate CA that contains this mapping is called the issuer CA and the subordinate CA whose policies have been mapped is called the subject CA. In mapping some or all of the subject CA's policies to the issuer's policies, the issuer CA effectually subordinates the subject CA. The result of this mapping is that users and computers in the issuer CA trust hierarchy who attempt to validate certificates from users and computers in the subject CA trust hierarchy can use their own certification path to perform validation. The separate trust hierarchy can be within the same intranet or in separate PKI environments over an extranet.
Mapping policies across trust hierarchies only requires that you install the issuer CA in your trust hierarchy. All the policies that are used in the subject CA trust hierarchy are mapped to the policies in your trust hierarchy, where you install the qualified subordinate CA. For this reason, you can establish a trust relationship, in fact subordinate, with a CA in another company by obtaining its policy object identifiers (also known as OIDs) and mapping them to the policy object identifiers that are used in your trust hierarchy.
The following steps are performed when using policy mapping for both issuance and application policies:
Determine the trust hierarchy with which you want to establish a trust relationship.
Establish the equivalence between the assurance levels that are used between the two trust hierarchies involved in the trust relationship.
Obtain the issuance and application policy object identifiers that are used in both trust hierarchies involved in the trust relationship.
Map the issuance and application policy object identifiers in the separate trust hierarchies and define their policy constraints in the CA certificate request for the qualified subordinate CA you are installing in your trust hierarchy.
Install the qualified subordinate CA with the policies, policy mappings, and policy constraints in your trust hierarchy.
When a user in the issuer CA trust hierarchy receives a file signed by a user in the subject CA trust hierarchy, the application of the user in your domain will attempt to validate the certificate using the validation path in your trust hierarchy. Because the object identifier in the certificate maps to an object identifier in your trust hierarchy, the certificate is validated. When a user in the subject CA trust hierarchy receives a file signed by a user in the issuer CA trust hierarchy, the subject CA user's application will attempt to validate the certificate using the validation path in its own certification hierarchy. Because the certificate contains the object identifiers used in the subject CA trust hierarchy, the certificate is validated.
Before defining the policy mapping, you need to obtain all the object identifiers that will correspond between the domains in the trust relationship. If you are creating a qualified subordinate CA for the purpose of establishing a trust relationship between trust hierarchies in different companies or PKIs, you will need to obtain the object identifiers used in the subject CA trust hierarchy by obtaining a certificate used in that hierarchy or from the CA administrator of that hierarchy. This information should only be passed under the most secure channels.
Issuance policy object identifiers in your trust hierarchy can only be mapped to issuance policy object identifiers in the foreign trust hierarchy. Similarly, application policy object identifiers in your trust hierarchy can only be mapped to application policy object identifiers in the foreign trust hierarchy.
For more information, see Qualified subordination; Qualified subordination overview; Name constraints; Issuance policies; Application policies; Policy constraints; Policy qualifiers; and Certificate Templates.
Constraining policy mapping
When a qualified subordinate CA uses policy mapping, you can use policy constraints to set the number of subordinate CAs below it in the certificate hierarchy that may map to its policies. An inhibit policy mapping policy constraint of 3 will inhibit policy mapping to subordinate CAs four levels below the qualified subordinate CA. A subordinate CA 5 levels below the qualified subordinate CA will not be allowed to define policy mappings.
Unexpected trust
When mapping policies between trust hierarchies in two different companies, the problem of unexpected trust could arise should a third company map its policy object identifier to the mapped object identifier of one of the two companies. For example:
The secure e-mail policy used by humongousinsurance.com is mapped to the secure e-mail policy in wideworldimporters.com.
A third company, northwindtraders.com, maps its secure e-mail policy to the policy of wideworldimporters.com.
This allows a user in northwindtraders.com to send signed e-mail to humongousinsurance.com that is considered valid because the e-mail application in humongousinsurance.com sees its own valid policy object identifier in the certificate issued by the CA in northwindtraders.com.
If humongousinsurance.com wants to prevent any additional policy mapping by northwindtraders.com from affecting its domain, it could place an inhibit policy mapping of 0 on its issuer CA. The CA for northwindtraders.com is considered a subordinate of the CA for wideworldimporters.com, and is thereby two levels below the issuer CA for humongousinsurance.com. Consequently, an inhibit policy mapping of 0 would cause the qualified subordinate CA for humongousinsurance.com to only process the policy mapping in certificates from subjects directly below it in its trust model (wideworldimporters.com) and refuse any certificates issued below that level (northwindtraders.com).