Evaluating Factors That Affect Extended Trusts

  • Article

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

Extending and refining your trust hierarchy is a critical step in the process of creating a secure PKI, and it involves complex decisions. It is important to define appropriate and inappropriate uses for certificates in your organization before you extend your CA infrastructure. Without proper planning, you might grant business partners and users more trust than you intend.

If you want to link your established Windows Server 2003 trust hierarchy with an external PKI, a number of factors can impact interoperability. Before you extend your CA infrastructure, evaluate the following features and standards in both PKIs:

  • Standards support

  • Algorithm support

  • CRL distribution points

  • Authority information access (AIA)

  • Authority key identifier (AKI)

  • Certificate extensions

  • Key length

  • Extended key usage (EKU)

  • Directory integration

Determine whether any other PKIs with which you need to establish trust support these features and standards, and how you can accommodate differences. Addressing these issues when you design your PKI can help you to ensure the extensibility and interoperability of your PKI environment.

Standards Support

A number of technical standards provide a basis for interoperability between Windows Server 2003 and other PKI applications. To promote third-party interoperability with the Windows Server 2003 API, Microsoft supports the following standards:

  • PKIX. Defines interoperable PKI standards for the Internet.

  • X.509. Describes the standard format of a certificate.

  • PKCS. Provides a standard for public key message exchanges.

  • TLS. Provides a secure and authenticated channel between hosts on the Internet above the transport layer.

  • S/MIME. Serves as a standard for secure e-mail across the Internet.

  • Kerberos authentication protocol. Provides a symmetric key framework for authentication in large networks.

  • PC/SC. Serves as a standard for integrating smart cards and smart card readers.

Most PKI vendors have adopted many or all of these PKI standards. Different vendors, however, can implement the standards in different ways. While it might be possible to link external PKI implementations to yours, this might involve making some changes to your existing design. For this reason, it is strongly recommended that you evaluate the external PKI to determine whether it meets all your critical requirements.

Algorithm Support

It is important for a PKI to interoperate with many different hardware vendors and to provide a hardware abstraction layer so that applications do not have to know where keys are stored.

Windows Server 2003 uses CryptoAPI to abstract hardware-based key management from applications, and it uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Many third-party CAs have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens such as smart cards. Because Windows 2000 and Windows Server 2003 require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003 does not support PKCS#11.

Note

  • The Windows Server 2003 PKI can use third-party CSPs, and can enroll users for certificates that have keys that were generated by third-party CSPs.

CRL Distribution Points

The CRL distribution point (CDP) extension in a certificate identifies how revocation information for the certificate can be obtained. If a CRL distribution point is not always available, certificate chain building can be delayed, causing inconvenience for the user. If a CRL is not available at the distribution point that has been specified in the certificate, CRL retrieval might even fail and the certificate will be considered invalid.

Note

  • Publish CDP URLs for all CAs so that users who need to know whether or not issued certificates have been revoked can find that information.

You need to compare any third-party CRL support with the Windows Server 2003 CRL support. For example, the third-party PKIs might not support the Windows Server 2003 CRL process, which includes the use of delta CRLs. Conversely, the Windows Server 2003 PKI might not support the methods of the third-party PKI for processing CRL information. Your extended PKI deployment plan needs to account for these differences.

In general, follow these guidelines when you configure the CDP extension:

  • If available, use Active Directory to support internal corporate clients.

  • Use an externally referenced and trusted Lightweight Directory Access Protocol (LDAP) directory to support business partners and customers.

  • Consider using HTTP distribution points, especially for certificates that will be used externally.

Authority Information Access

The Authority Information Access (AIA) extension is a pointer to the most currently published CA certificate of a CA. The AIA extension helps clients find CA certificates dynamically during chain building. The Windows Server 2003 PKI uses this extension to assist in building trust chains to validate certificates.

It is recommended that you publish AIA URLs for all PKIs for which users might need to retrieve up-to-date CA certificates. Whether a CA is online or offline, and whether it is a root, intermediate, or issuing CA, using the AIA extension minimizes the likelihood that PKI clients will encounter unverified certificate chains or revocation data. Such encounters can result in unsuccessful VPN connections, failed smart card logons, or unverified e-mail signatures.

Some third-party PKIs do not provide the AIA extension. In this case, parent certificates need to be distributed to domain clients so that the certificates are available before the chain building process begins. Cross-certificates must also be available locally on domain clients, because there is no information in a certificate specifying where it can be found.

Authority Key Identifier

The Authority Key Identifier (AKI) extension provides a means to identify the public key of the CA that validates the signature on a CRL. This identification is based on either the subject key identifier (SKI) or the issuer name and serial number from the certificate issued by the CRL issuer. The AKI extension is useful in cases when a CRL issuer has more than one signing key.

An organization that expects its PKI certificates to be used by other Windows Server 2003 PKIs must populate the Authority Key Identifier extension with a unique key identifier and an issuer name and serial number. The Windows Server 2003 PKI attempts to construct certificate chains by using the issuer name and serial number in the AKI first, and then the subject key identifier.

Note

  • By default, Windows Server 2003 does not automatically add issuer names and serial numbers to the AKI extension. This data must be added manually by means of Certutil.exe, although in most cases it is not necessary to do so.

Certificate Extensions

Not all certificate extensions are universally recognized. If a CA does not recognize a certificate extension in a request and it has been marked critical, it rejects the certificate. Unless you intend to limit the use of the certificate to a specific application that understands the critical extension, avoid putting critical extensions in certificates because it limits interoperability.

Key Length

When different PKIs support different minimum and maximum key lengths, an interoperability problem results. Be sure that your internal PKI and the external PKI support the necessary encryption keys.

Extended Key Usage

The Extended Key Usage (EKU) extension indicates the purposes for which the public key contained in the certificate can be used. The Windows Server 2003 PKI uses the EKU extension to indicate certificates that support special functions, such as IPSec and EFS file encryption backup. The EKU extensions of other organizations might be used for different purposes.

Directory Integration

Windows Server 2003 PKI certificates can be published to any directory or repository, although the default CA exit module only supports Active Directory. However, by default, a Windows Server 2003 PKI relies on Active Directory and the LDAP for authentication, including smart card logons and certificate autoenrollment, as well as for certificate management.

With Microsoft Certificate Services, certificates issued by a third-party CA can be associated with a Windows Server 2003 user account stored in Active Directory. This is possible because applications such as Internet Explorer and Internet Information Services (IIS) can be used to authenticate a user to an account stored in Active Directory, based on the UPN name information in a certificate. The account to which the certificate maps provides information about user access rights on the server. This is an extremely powerful feature for Web-based applications and third-party CAs because it combines strong authentication by means of public key technology with the native authorization model of Windows Server 2003. For example, to enable extranet and remote access scenarios without requiring the application and certificate to manage access rights, administrators can use certificates from partner companies and map them to accounts in Active Directory by means of one-to-one or many-to-one mappings.

For more information about using one-to-one and many-to-one mapping, see "Map certificates to user accounts" later in this chapter.