Qualified subordination
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Qualified subordination
Qualified subordination is an extension of standard certification authority (CA) subordination that allows you to:
Define the namespaces for which a subordinate CA will issue certificates.
Specify the acceptable uses of certificates issued by a qualified subordinate CA.
Create trust between separate certification hierarchies.
For more information, see Qualified subordination overview.
Qualified subordination properties
Qualified subordination properties are defined in the CA certificate request for a subordinate CA. The CA certificate that is used to install a qualified subordinate CA contains extensions where the different qualified subordination properties are listed. The following table describes the extensions in the CA certificate that are used to install a qualified subordinate CA:
| Extension | Description |
|---|---|
The range of namespaces that are permitted or excluded by the qualified subordinate CA and its subordinates. |
|
Policies |
The list of acceptable policies for a certificate, included in the certificates issued by the qualified subordinate CA. These policies are identified in a certificate by object identifiers (also known as OIDs) and include both Issuance policies and Application policies policies. The object identifiers that are used are enterprise-dependent (or dependent within the scope of the object identifiers you use). The object identifier for an application in one PKI deployment must be different from another. |
Determines how a policy object identifier from one trust hierarchy is mapped to a policy object identifier of another trust hierarchy. |
|
Defines the certification path length required and allowed for policy identifiers and policy mapping. |
All features of qualified subordinate CAs are new to the Windows Server 2003 family and are not available on Windows 2000 Server. To use these new features, you must use a Windows Server 2003 certification authority.
Note
- The constraints and policy types listed above are defined in RFC 2459. For more information on RFCs, see the RFC Editor Web site.
Intranet and extranet qualified subordination
Qualified subordination may be used in both intranet and extranet environments. Intranet-qualified subordination involves a parent CA issuing a CA certificate to a qualified subordinate CA within a company's intranet. For example, you might install a qualified subordinate CA to issue certificates for a specific network domain in your network. Extranet qualified subordination establishes trust between CAs in separate networks.
Extranet qualified subordination is also commonly called cross-certification because trust is being established across separate certification hierarchies. For Windows Server 2003 certification authorities, cross-certification is synonymous with qualified subordination.
Name constraints
Name constraints specify a range of permitted and excluded namespaces that a qualified subordinate CA and its subordinates will use when evaluating certificate requests. A user requesting a certificate from a qualified subordinate CA is identifiable by one or more of the namespaces required by the certificate template for which the request is made. Name constraints are defined using the namespaces used in your network, such as DNS domain names. By permitting or excluding a namespace, the qualified subordinate CA permits or exclude all subjects that are identifiable by that namespace from receiving one of its certificates.
Name constraints apply to subtrees of a namespace. A permitted name constraint defines the namespace within which the CA may issue certificates. An excluded name constraint is used to exclude a subspace of a permitted namespace. For example, a CA with the permitted name constraint example.microsoft.com may have an excluded name constraint of TestDomain.example.microsoft.com. In this case, the CA and its subordinates will issue certificates for users within the example.microsoft.com namespace but not for users within the TestDomain.example.microsoft.com namespace.
Name constraint definition and usage
When the CA certificate for the qualified subordinate CA is created, name constraints are defined to determine what namespaces the qualified subordinate CA will permit or exclude. When the installed qualified subordinate CA receives a certificate request from an entity such as a user, name constraints determine whether the qualified subordinate CA will issue the certificate.
When someone submits a certificate request for a qualified subordinate CA to the parent CA, the parent CA uses the certificate path to verify that the qualified subordinate CA will not permit names that are excluded by any other CA in the certification path. If the name constraints defined in the CA certificate request permit names that a CA in the certification path excludes, then the certificate request is denied. If the permitted namespaces defined in the CA certificate request do not conflict with the permitted namespaces of the CAs in the certification path, then the CA certificate request is successful.
For a certificate request that is submitted to a qualified subordinate CA to be successful, all namespaces identified with the user in the certificate request must be within permitted namespaces and none may be within an excluded namespace.
The following name forms are allowed as name constraints. The RFCs listed may be found at the RFC Editor Web site.
| Name form | Resource |
|---|---|
Directory name (for example, Active Directory distinguished name) |
|
DNS |
RFC 1024 |
RFC 822 |
|
URI/URL |
RFC 1738 |
User principal name (UPN) |
For more information, see Active Directory naming. |
IP address |
IPv4 RFC 791; IPv6 RFC 1883 |
Policies
Certificate policies describe the policies according to which a certificate was issued and define how it may be used. There are two types of policies used in qualified subordination:
Issuance policies
Application policies
Both policy types can be included in all types of certificates, including CA certificates and user certificates. This availability is in contrast to name constraints, policy mapping, and policy constraints, which are only used in creating the CA certificate for a qualified subordinate CA.
The policies that are available to a certificate template are first defined in the CA certificate for the qualified subordinate CA that will use certificate templates. Each policy listed has a corresponding object identifier (also known as an OID) identifying the policy. The object identifiers used are restricted to that policy for the entire public key infrastructure (PKI). The object identifiers assigned to policies in one PKI may be mapped to the policies in a separate PKI to facilitate trust. For more information, see Mapping policies between trust hierarchies.
The issuance and application policies that are placed on a qualified subordinate CA must be within the set of policies object identifiers defined for all the CAs in the certification path of the qualified subordinate CA. When a qualified CA certificate request is evaluated, the policy object identifiers contained in the request are evaluated against the policy object identifiers used in the entire certification path to determine that the policy object identifiers contained in the request are a subset of the object identifiers used in the path. For a qualified subordinate CA to use issuance policies, policies must be present at every CA in the certificate hierarchy between the root CA and itself. For this reason, policy cannot be removed from a certification hierarchy, but can only be constrained when installing a qualified subordinate CA.
Issuance policies
The issuance policies that are contained in a certificate identify the assurance level of the certificate's subject when that subject presents the certificate to another entity. Assurance describes the extent to which a CA trusts a subject's identification; for example, whether the user is recognized by domain authentication only or if the user has passed multiple authentication stages. Assurance levels are defined for a PKI and issuance policies are used to represent them in certificates.
When a subject uses a certificate that contains an issuance policy, security entities can identify the assurance level of that subject and react accordingly. The security credentials that these assurance levels represent depend on how the policies are defined in the PKI.
For more information, see Issuance policies.
Application policies
Application policies are included in a certificate because they are required by the applications that will receive these certificates. Some applications have policy requirements and maintain a list of the policies that they will accept. When an application receives signed information, it compares the application policy object identifiers in the received certificate to its list or required policies. For example, a remote access server may require that a Client Authentication application policy be present in a certificate that is presented by a client performing a remote logon.
Application policies are similar to the Extended Key Usage extension in a certificate, as both use one or more object identifiers to prescribe how the public key in a certificate must be used. Extended Key Usage is still supported by Windows Server 2003 CAs to provide for PKIs that use this extension, but application policies replace them.
For more information, see Application policies.
Policy mapping
Policy mapping allows you to map a certificate policy object identifier in one trust hierarchy to a policy object identifier used in another trust hierarchy in your intranet or extranet. The policy mappings are defined in the CA certificate request for a qualified subordinate CA. Each pair of policies that is configured on the qualified subordinate CA indicates that it considers its trust hierarchy's policies equivalent to those in the other trust hierarchy.
For an example of policy mapping, see Qualified subordination overview.
When mapping the policies used in an external trust hierarchy, the qualified subordinate CA that contains the policy mappings is said to subordinate the CA in the external trust hierarchy whose policies it has mapped. This subordination does not require the administrator of the external trust hierarchy's CA to perform any task. This allows you to set up a trust relationship with another trust hierarchy by subordinating a single subordinate CA or the root CA of the external PKI.
For more information, see Mapping policies between trust hierarchies.
Policy constraints
Policy constraints restrict certificate validation in two ways:
They require that each CA certificate in a certification path contain a specific policy.
They specify the number of CA certificates that are permitted in a certification path before policy mapping is no longer allowed.
Policy constraints are applied to both issuance and application policies. For more information, see Policy constraints.
Unexpected trust
When mapping policies between trust hierarchies in two different companies, there could be a problem of unexpected trust if a third company maps its policy object identifier to the mapped policies of one of the two companies. In this case, the third company is trusted by both of the other companies, which may not be wanted. In addition, either of the companies could make modifications to their certification hierarchies that would have the same effect. Policy constraints resolve this unexpected trust by restricting the certification path depth in which policy mapping may be used.
For more information, see Mapping policies between trust hierarchies; Policy constraints
Notes
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.
Qualified subordination is performed by the parent CA on any subordinate CA and can therefore by applied to any type of CA, such as Windows NT 4.0, Windows 2000 Server, or other CAs.
Qualified subordinate CA certificate renewal is the same as standard subordinate CA renewal.
When qualified subordinate CA certificates and cross-certificates are revoked, they should also be deleted from the Active Directory directory service. This deletion is not required for security reasons, but is considered a best practice, because it also removes the certificates from the Local Machine certificates store of client computers.