CAPolicyinf File Sections

Within the CAPolicy.inf file, there are several predefined sections, each of which defines specific settings for Certificate Services. These sections and related decisions regarding their contents are outlined here, as well as whether the section applies to root CA installations, subordinate CA installations, or to both root and subordinate CA installations.

[Version]

The [Version] section defines that the .inf file uses the Windows NT format. This section must exist for both root and subordinate CA installations. It contains a single line:

Signature^ "$Windows NT$"

[PolicyStatementExtension]

The [PolicyStatementExtension] section defines a CA's CPSs and certificate policies. This section's inclusion depends on the number of tiers in the CA hierarchy.

In a single-tier CA hierarchy, the [PolicyStatementExtension] and related [Policy-Name] sections are defined at the root CA. In a two-tier CA hierarchy, you should include the [PolicyStatementExtension] and related [PolicyName] sections at each issuing CA in the hierarchy. In a three-tier CA hierarchy, the [PolicyStatementExten-sion] and related [PolicyName] sections should be defined at the policy CAs on the second tier. If different CPSs are required, they are defined at each policy CA.

In the [PolicyStatementExtension] section, you define one or more subsections. Within the subsections, you define a minimum of three settings:

■ Object identifier (OID). An object identifier can be applied to each CPS. The OID is an identifier that is tied to the CPS or, if multiple policies are defined, to each CA's certificate policy.

Note There is a practical limit to the number of certificate policies that can be included in a CA certificate. The Active Directory schema only allows a maximum string length of 4,096 bytes for all CPS information, including OID, notification text, and URL. The total length of the certificate policy entries must be less that 4,096 bytes.

Where Do I Get an OID?

An OID is a unique sequence of numbers that identifies a specific directory object or attribute. You can define an OID for a CPS as either a public OID or a private OID.

If your organization plans to use PKI-enabled applications in conjunc tion with other organizations, you must obtain an OID from a public number-assignment company to ensure that your OID will be unique on the Internet. Sources for public OIDs include:

■ The Internet Assigned Numbers Authority (IANA). This source issues free OIDs under the Private Enterprises arc. Every OID assigned by the IANA begins with the numbers 1.3.6.1.4.1 representing iso(1).org(3).dod(6).internet(1).private(4).enterprise(1).

Note An arc is the term used to reference a specific path in the global OID tree maintained by the International Organiza tion for Standardization (ISO) and the International Telecommu nication Union (ITU). This global OID tree is sometimes referred to as the joint ISO/ITU-T tree. For example, the Private Enterprises arc contains all OIDs that begin with 1.3.6.1.4.1.

■ The American National Standards Institute (ANSI). This source issues OIDs for purchase under the U.S. Organizations arc of the ANSI OID tree. Every OID assigned by the ANSI begins with the numbers 2.16.840.1 rep resenting joint-iso-itu-t(2).country(16).US(840).US company arc(1).

■ Other countries. Each country has its own OID-management organi zation. The easiest way to find the organization for a given country is to perform a Google search (www.google.com) with the search phrase Country (where Country is the name of the given country) and "Object Identifier." Here are some examples of the arcs available within the joint ISO/ITU-T tree:

■ Canada: joint-iso-itu-t(2).country(16).canada(124)

■ Netherlands: joint-iso-itu-t(2).country(16).netherlands(528)

■ Switzerland: joint-iso-itu-t(2).country(16).switzerland(756)

■ Thailand: joint-iso-itu-t(2).country(16).thailand(764)

■ Notice. The Notice line provides the text that appears when a user clicks the Issuer Statement button when the CA's certificate is displayed. The Issuer Statement is typically the title of the CPS and does not display any details about the CPS. Remember that you are limited to 4,096 bytes of data in the Certificate Policies extension—including the entire CPS in the Notice line will result in a very large CA certificate with the entire text of the CPS in the CA certificate.

■ URLs. Multiple URLs can be provided for the CPS. The URLs provide links to the actual text of the CPS. When you view the Notice text, a button labeled More Info opens a browser window that displays the content of the URL specified in the URL line. Typically, the URL is a Hypertext Transfer Protocol (HTTP) or File Transfer Protocol (FTP) URL.

You can also generate a private OID based on your forest's globally unique identifier (GUID) within the Microsoft IANA-assigned tree. If you decide to use these OIDs, you will have an OID assigned from 1.3.6.1.4.1.311.21.8.a.b.c.d.e.1.402 (where a.b.c.d.e is a unique string of numbers based on your forest's GUID).

Note Use this private OID tree only if you do not foresee using the OIDs in conjunction with other organizations and your organization is unwilling to obtain a free OID from the IANA. If you plan on using PKI-enabled applica tions within other organizations, obtain a free OID tree from the IANA or buy a tree from the ANSI.

Tip You can obtain your forest's private OID by opening the Certificate Tem plates (certtmpl.msc) console as a member of the Enterprise Admins group. In the console tree, right-click Certificate Templates and click View Object Identifiers. In the resulting dialog box, you can choose the High Assurance Object Identifier and click the Copy Object Identifier button. Once you copy the OID, you can plug your forest's values into the placeholders a.b.c.d.e and remove any trailing digits.

[AuthorityInformationAccess] and [CRLDistributionPoint]

The [AuthorityInformationAccess] and [CRLDistributionPoint] sections specify the publication points for a root CA's certificate and CRL. Subordinate CAs disregard these sections because the CRL and CA certificate distribution points are defined in the configuration of the parent CA, not at subordinate CAs.

There are two strategies you can use when designing the CA certificate and CRL publication points for a root CA. Choosing which strategy to follow depends on your organization's security policy and the PKI-enabled applications it deploys.

The first strategy is to not publish CA certificate and CRL retrieval URLs in the root CA's certificate. By excluding the Authority Information Access (AIA) and CRL Distribution Point (CDP) extensions from the root CA certificate, you block the certificate chaining engine from checking the root CA certificate's revocation status. The root CA certificate is designated as trusted by adding the certificate to the trusted root CA store at client computers. If the root CA certificate is compromised, you must redeploy your entire PKI rather than just revoke the root CA certificate.

Most applications do not check revocation status of the root CA certificate unless it contains a CDP extension. Removing the AIA and CDP extensions from the root CA certificate ensures that all applications bypass revocation checking on the root CA certificate.

To prevent the inclusion of the AIA and CDP extensions in the root CA certificate, include the following lines in your CAPolicy.inf file:

[AuthorityInformationAccess] Empty = true

[CRLDistributionPoint] Empty = true e>

The second strategy is to define the exact URLs where you publish the root CA's certificate and CRL. The order in which you define the URLs is important for the cryptoAPI, as it dictates the search order that a Windows client uses when downloading the CA certificate or CRL.

If you decide to define AIA and CDP URLs for the root CA certificate, you can use predefined variables, rather than coding the actual URLs. Windows Server 2003 provides the variables shown in Table 6-2 for defining AIA and CDP URL paths.

Note Alternatively, you can just add [AuthorityInformationAccess] and [CRLDistributionPoint] with no entries in the sections to suppress the inclu sion of AIA and CDP extensions in the root CA certificate.

Note Design considerations for the URL order of the AIA and CDP exten sions are discussed in detail in Chapter 9.

Table 6-2 AIA and CDP Variable Definitions

Variable

Name

Description

%1

ServerDNSName

The CA computer's DNS name

%2

ServerShortName

The CA computer's NetBIOS name

%3

CAName

The CA's logical name

%4

CertificateName

The name of the CA's certificate file

%5

DomainDN

Not used in the Windows Server 2003 PKI

%6

ConfigDN

The Lightweight Directory Access Protocol (LDAP) path of the forest's configuration naming context for the forest

%7

CATruncatedName

The CA's "sanitized" name

%8

CRLNameSuffix

The CRL's renewal extension

%9

DeltaCRLAllowed

Indicates whether delta CRLs are supported by the CA

%10

CDPObjectClass

Indicates that the object is a CDP object in Microsoft Active Directory

%11

CAObjectClass

Indicates that the object is a CA certificate object in Active Directory

When variables are used in the CAPolicy.inf file, the installation of Certificate Services parses the file and replaces the variables with the actual names implemented by the CA. For example, if you do not define a [CRLDistributionPoint] section, a root CA implements the following default paths for CRL publication:

■ %windir%\System32\CertSrv\CertEnroll\%3%8%9.crl

■ ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services, CN=Services,%6%10

Likewise, if you do not define an [AuthoritylnformationAccess] section within a CAPolicy.inf file, a root CA implements the following default paths for CA certificate publication:

■ %windir%\system32\CertSrv\CertEnroll\%1_%3%4.crt

■ ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11

Note Although presented here, including AIA and CDP extensions in the root CA certificate is not recommended. You can leverage this information on using variables when defining publication points for CRLs and CA certifi cates for subordinate CAs.

[EnhancedKeyUsageExtension]

This section is used to restrict the types of certificates a CA can issue.For example, if you want to restrict a CA to issuing certificates for Client Authentication, Server Authentication, and Secure Email, you would define the [EnhancedKeyUsageExtension] as shown here:

[EnhancedKeyUsageExtension]

OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication OID = 1.3.6.1.5.5.7.3.4 ; Secure Email

Note These OIDs are predefined by the IANA or by Microsoft. You can view the list of predefined OIDs in the Certificate Templates console using the same method you use to identify your forest's privately assigned OID tree.

[BasicConstraintsExtension]

The [BasicConstraintsExtension] section allows you to define path-length restrictions. A path-length restriction allows you to limit the depth of your CA hierarchy. For example, if you only want one more tier below the current CA, you can define the [BasicConstraintsExtension] section as shown here:

[BasicConstraintsExtension] pathlength = 4

Note All CA certificates have a Basic Constraints extension, even if you do not define the section in the CAPolicy.inf file. The Basic Constraints exten sion indicates whether the certificate is issued to a CA or to a user, com puter, service, or network device. CA certificate identification allows the chaining engine to determine whether the certificate can be used to sign other certificates.

[certsrv_server]

The [certsrv_server] section has entries that apply to all CAs in the CA hierarchy. The following entries can be defined in this section:

■ RenewalKeyLength. The requested length of the CA's private key and public key when the CA certificate is renewed. The value should match the value assigned to the CA's key length during initial installation, unless you decide to modify the length of the CA's certificate at renewal time.

■ RenewalValidityPeriod. The validity period's unit of measurement. Accepted values are years, weeks, and days, though use of anything other than years is uncommon.

■ RenewalValidityPeriodUnits. The specific number of units for the validity period. For example, if you configure a CA with a 15-year validity period, the RenewalValidityPeriodUnits value is 15.

Note You cannot set the initial CA key length and validity period in the CAPolicy.inf file. The value at installation is configured in the installation wiz ard for a root CA and is defined by the parent CA for all subordinate CAs. The CAPolicy.inf file only contains the values used when you renew the CA certificate for all CAs in the CA hierarchy.

■ CRLPeriod. The CRL publication interval's unit of measurement. The default value is days, but years, weeks, days, and hours are acceptable.

■ CRLPeriodUnits. The specific number of units for the CRL publication interval. The default value is seven, but this value is typically changed based on the CA's design.

■ CRLDeltaPeriod. The unit of measurement for the delta CRL publication interval. The default unit or value is days, but years, weeks, days, and hours are acceptable.

■ CRLDeltaPeriodUnits. The specific number of units for the delta CRL publication interval. The default value is 1, but this value is typically changed based on the CA's design.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

  • mikolaj
    Where is the capolicy.inf file in server 2003?
    3 years ago
  • CLARA PISANI
    Where is CDP variable "ServerDNSName" defined?
    1 year ago

Post a comment