Qualified subordination overview

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

Qualified subordination overview

Qualified subordination allows you to place certificate issuance constraints on subordinate CAs and to place usage constraints on the certificates they issue. With qualified subordination, you can focus subordinate CAs according to specific certification needs and administer your public key infrastructure (PKI) more efficiently.

Certificate-based trust between trust hierarchies

Qualified subordination also allows you to establish trust between CAs in separate trust hierarchies. This type of trust relationship is also called cross-certification. With this trust relationship, qualified subordination is not limited to subordinate CAs. Trust between hierarchies may be established using a subordinate CA in one hierarchy and the root CA in another hierarchy.

Additional levels of security controls

Qualified subordination extends your trust hierarchy by allowing you to place additional trust conditions within and between the domains in your PKI. With qualified subordination, the qualified subordinate CAs in your trust hierarchy can each have different rules governing how they will issue certificates and how their certificates may be used. For more information on qualified subordination, see Qualified subordination.

Qualified subordination extensions

Each qualified subordination constraint adds an additional trust condition and more narrowly defines the scope of a CA. These conditions are defined in the certificate extensions of a qualified subordinate CA certificate. When you install a qualified subordinate CA, you define the following extensions in its CA certificate:

Extension Description

Name Constraints

Restricts the namespaces that are permitted or excluded by the qualified subordinate CA and its subordinates when issuing certificates.

Policies

Defines the list of acceptable issuance and application policies for certificate usage. These policies are identified in the certificate by object identifiers (also known as object identifiers).

Policy Mapping

Allows a policy from one domain to be mapped onto a policy of another domain.

Policy Constraints

Restricts the subordination levels in a certificate hierarchy to which a policy is applied. These extensions are used in conjunction with issuance and application policies only.

All constraints that are placed on a qualified subordinate CA are defined in the complete request for the CA certificate that is used to install the qualified subordinate CA. The complete request is a CMC certificate request that has been generated using an information file (.inf file). All qualified subordinate CA policies, constraints, and mappings can be defined using an information file (.inf). In order to modify the policies and constraints placed on a qualified subordinate CA after installation, the administrator of that qualified subordinate CA's parent CA must reissue the CA certificate for the qualified subordinate CA, thereby reinstalling it. For more information, see Perform qualified subordination.

The constraints and policy types listed above are defined in RFC 2459. For more information on RFCs, see the RFC Editor Web site.

For more information, see Name constraints, Policy constraints, Mapping policies between trust hierarchies, and Policy qualifiers.

Qualified subordinate CA scenarios

The following sections show how qualified subordination can be used.

Name constraints scenarios

The Humongous Insurance Company has two Active Directory directory service domains hosted in different geographic locations, one domain in North America and one domain in South America. The company's PKI administrator wants the qualified subordinate CAs that are deployed in each domain to issue certificates for users in their local domain only. The two Active Directory domains are northamerica.humongousinsurance.com and southamerica.humongousinsurance.com.

The administrator performs the following steps:

  1. Installs a qualified subordinate CA for the domain northamerica.humongousinsurance.com with the following permitted name constraints:
Name constraint format Permitted name constraint Example

Distinguished name

DC=northamerica,DC=humongousinsurance,DC=com

CN=Mike Danseglio,CN=Users,DC=northamerica,DC=humongousinsurance,DC=com

DNS domain name

.northamerica.humongousinsurance.com

hostname.northamerica.humongousinsurance.com
  1. Installs a qualified subordinate CA for the domain southamerica.humongousinsurance.com with the following permitted name constraints:
Name constraint format Permitted name constraint Example

Distinguished name

DC=southamerica,DC=humongousinsurance,DC=com

CN=Don Funk,CN=Users,DC=southamerica,DC=humongousinsurance,DC=com

DNS domain name

.southamerica.humongousinsurance.com

hostname.southamerica.humongousinsurance.com

As a result, the certificate issuance behavior of each qualified subordinate CA is restricted to users in their respective domains. If a user in northamerica.humongousinsurance.com requests a certificate from the qualified subordinate CA for southamerica.humongousinsurance.com, the request is denied because the namespace specified in a permitted name constraint automatically excludes any other namespaces.

For more information, see Name constraints.

Policy scenarios

Humongous Insurance wants to use application and issuance policies to configure the following PKI scenarios:

  • Only allow remote network logon using smart card authentication.

  • Create a certificate that allows selected users to make purchases of up to one million dollars.

Only allow remote network logon using smart card authentication

To restrict remote network logon to only allow smart card authentication, the company performs the following steps:

  1. Configures their remote access server to require smart card authentication.

  2. Installs and configures a qualified subordinate CA to issue smart card logon certificates containing a specific application policy that is required by the remote access server.

  3. Distributes smart cards containing the specific application policy that is required by the remote access server.

When a user attempts to log in, the following steps occur:

  1. Users attempt to log on remotely over a dial-up connection using their smart cards.

  2. The remote access server software checks to see if the smart card contains the required application policy.

  3. If the smart card contains the required application policy, then the remote access server software forwards the logon request to the nearest domain controller.

  4. The domain controller grants the user access to the network.

Create a certificate that allows selected users to make purchases of up to one million dollars

To create a certificate that allows selected users to make purchases of up to one million dollars, the company performs the following steps:

  1. Creates a signing certificate for the company’s accounting department that contains a specific issuance policy object identifier (also known as an OID).

  2. When the company creates a Million Dollar Purchase certificate template, it adds an issuance requirement for the Accounting department’s specific issuance policy object identifier.

  3. The user creates a million dollar purchase request using the template.

  4. The accounting department manager is notified that there is a pending certificate request which she must accept or reject.

  5. The accounting department manager signs the Million Dollar Purchase certificate request with the signing certificate that contains the specific issuance policy object identifier.

  6. The signed request is sent to the company's CA.

  7. The company’s CA receives the signed request, determines that the issuance requirement for the certificate template has been met by identifying the accounting department’s specific issuance policy object identifier, and issues the Million Dollar Purchase certificate to the user.

Policy mapping scenario

Two companies, Humongous Insurance and Northwind Traders, enter into a partnership and want to establish a trusted communication path where the $1 million issuance policy of Humongous Insurance is considered equal with the two million dollar issuance policy of Northwind Traders.

The CA administrator for the Humongous Insurance domain humongousinsurance.com performs the following steps:

  1. Obtains the two million dollar issuance policy object identifier for Northwind Traders under a very secure channel.

  2. Defines the policy mapping between Humongous Insurance's one million dollar issuance policy and Northwind Traders' two million dollar issuance policy.

  3. Installs a qualified subordinate CA in the Humongous Insurance trust hierarchy containing the policy mapping.

The policy mapping results in allowing purchase orders signed in the Northwind Traders trust hierarchy to be validated by the trust hierarchy of Humongous Insurance.

For more information, see Mapping policies between trust hierarchies; Policy constraints

Enterprise and stand-alone qualified subordinate CAs

Windows Server 2003 qualified subordinate CAs can be installed as enterprise qualified subordinate CAs or stand-alone qualified subordinate CAs. The difference between the two types of qualified subordinate CAs is how they identify users requesting certificates. Enterprise qualified subordinate CAs require the use of Active Directory and stand-alone qualified subordinate CAs do not.

Enterprise qualified subordinate CAs identify users by some or all of their Active Directory user object attributes. When an enterprise qualified subordinate CA receives a certificate request from a user, it identifies the user according to the authentication credentials that are used by that user during network logon and uses that information to query the Active Directory and obtain the user's user object attributes.

When users request certificates from a stand-alone qualified subordinate CA, the user fills out a Web page form where the user specifies information such as a name, e-mail address, company name, department, and country/region. This information is included in the fields of the certificate request that is sent to the stand-alone qualified subordinate CA, which uses this information to determine certificate issuance. A stand-alone CA cannot publish any issued certificates to Active Directory other than its own CA certificate. However, the more common scenario is to have a stand-alone root CA with an enterprise qualified subordinate CA. For more information, see Stand-alone certification authorities.

Verification paths for qualified subordinate CAs

Each qualified subordinate CA's policies and constraints are defined according to a subset of its certification path's policies and constraints. Using qualified subordination, boundaries are established within the certification hierarchy to ensure that all CAs in a hierarchy's paths issue certificates within certain constraints. These constraints may be maintained or more narrowly defined the further the certification hierarchy branches from its trust anchor (root CA).

The following graphic shows how qualified subordinate CAs can only issue CA certificates according to a subset of the rules permitted by their certification path. In the graphic, policies are used as an example and are represented as numbers to demonstrate a subset.

Verification paths for qualified subordinate CAs

Qualified subordination certification hierarchy restrictions

Qualified subordinate CAs CA 1, CA 2, and CA 3 have defined policies from which the qualified subordinate CAs below them may select policies. With each level of the certificate hierarchy, fewer of the acceptable policies are used and the qualified subordinate CAs are more limited in scope.

No trust model will permit the qualified subordinate CA to allow certificate issuance behavior that its certificate path does not allow. To enforce this rule, the following process is followed when a parent CA receives a CA certificate request:

  1. The CA verifies the certificate request against all the constraints placed on all the CAs from its root CA down its certification hierarchy to itself.

  2. At each intersection in the certification hierarchy, the issuing qualified subordinate CA compares the information contained in the certificate request with those set at the existing CA.

  3. If there are no conflicts between the information in the certificate request and those placed on the CAs in the certification hierarchy, then the certificate is issued. If there is a conflict, the certificate request is denied.

Notes