Using Issuance Policies

  • Article

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

You can use issuance policies to define the extent to which your organization trusts the identity presented in a certificate. For example, you can set an issuance policy stipulating that you only trust certificates that were issued during a face-to-face meeting with a network administrator, such as when a smart card certificate is issued.

An object identifier must describe every issuance policy that you define. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the issuance requirements associated with the issuance policy object identifier.

Note

  • Issuance policy is only available on Windows Server 2003 CAs. Windows 2000 does not provide issuance policy.

You can use a specific certificate template to define one or more issuance policy object identifiers that need to be included in any certificates issued. Windows Server 2003 includes four predefined issuance policies:

  • All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

  • Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used to represent certificates that are issued with no additional security requirements.

    Note

    • The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest.

  • Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face to face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.

  • High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from a Windows Server 2003, Enterprise Edition CA.

In addition, you can create your own object identifiers to represent custom issuance policies. For example, two organizations involved in a purchaser/seller relationship can define custom object identifiers to represent digital signature certificates for specific purchase amounts. In such a case, an object identifier can be defined for purchase between $100,000 and $500,000 and another object identifier can be defined for purchases greater than $500,000. Applications can then use these object identifiers to recognize whether a person had the appropriate signing authority for a specific volume purchase.

Applying Policy Mapping

In many cases, the administrators of two PKIs define their own policies and object identifiers. In some cases these policies are identical, but in most cases there are small differences between them. For example, one organization might stipulate that one physical form of identification is sufficient to grant a certificate request, while a second organization requires three forms of physical identification to grant a similar request. In these cases, you need to negotiate with the administrators of the other PKI to define terms of equivalence before the cross-certified relationship can be established. This is called policy mapping.

Policy mapping enables interoperability between two organizations that apply similar issuance and application policies, but have deployed different object identifiers. If the policy object identifier (for example, 1.2.3.4) of one company represents a specific function, and the policy object identifier of another company (for example, 11.22.33.44) represents the same function, they can be mapped, so that 11.22.33.44 and 1.2.3.4 are interchangeable.

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 policies of the subject CA to the policies of the issuer, the issuer CA effectively subordinates the subject CA. The result of this mapping is that users and computers in the issuer CA trust hierarchy can use their own certification paths to validate certificates from users and computers in the subject CA trust hierarchy. The separate trust hierarchy can be within the same intranet or in separate PKI environments over an extranet.

To apply policy mapping

  1. Identify the trust hierarchy with which you want to establish a trust relationship.

  2. Establish equivalence in the assurance levels used by the two trust hierarchies involved in the trust relationship.

  3. Obtain the issuance and application policy object identifiers used in both trust hierarchies involved in the trust relationship.

  4. 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 that you are installing in your trust hierarchy.

  5. Install the qualified subordinate CA with the policies, policy mappings, and policy constraints in your trust hierarchy.

Constraining Policy Mapping

You can refine policy mapping by setting parameters for how the issuance policy defined in qualified subordination affects other CAs below the qualified subordinate CA. These parameters can help to limit unplanned trust relationships. The following two settings define this relationship:

  • Require explicit policy. Specifies the number of certificates that can exist in the hierarchy below a certificate before an explicit policy must exist. For example, if the explicit policy is configured with a setting of three, the defined issuance policy must exist for three layers of the hierarchy. The CA on which the qualified subordination is defined is the first level.

  • Inhibit policy mapping. Specifies the number of additional certificates that can appear in the path before policy mapping is no longer permitted. For example, an inhibit policy mapping value of three restricts the policy mapping to only three levels of CAs below the qualified subordinate CA.