Public Key Technology in Windows 2000

Like this article? We recommend

Secure Networking With Windows 2000 and Trust Services

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Secure Networking With Windows 2000 and Trust Services

Learn More Buy

Public Key Infrastructure

The public key infrastructure in Windows 2000 [MICR00A, MICR00B] supplies public key capabilities to applications that use certificates for making automated identity assessments and trustworthiness decisions. Applications leverage the Window 2000 PKI to establish the quality of protection they need before they process a transaction or open a communications channel. This section covers some of the Windows 2000 PKI features.

Trust Models

This section discusses three models for controlling the flow of trust in a network. Refer to the section Structures among Multiple Certification Authorities in Chapter 3 and the section Models for CA Structures in Chapter 5 for related information.

The Rooted Hierarchical Trust Model

In a rooted hierarchical trust model, trust starts with one top-level root CA and flows down the hierarchy through a chain of subordinate CAs to end-entities. All CAs in a hierarchical PKI are subordinates to other, superior CAs, except for the top-level root CA, which has a self-signed certificate and does not have a superior CA. Members of a hierarchical PKI need to trust only the top-level root CA in order to trust all the other member CAs. Numerous PKI products and third-party commercial CA service providers-notably Microsoft and VeriSign -support the rooted hierarchical trust model. Figure 4-2 shows a three-level hierarchical PKI.

A new CA can enter a hierarchical PKI through the process of subordination, in which an existing CA issues a certificate for the new CA. The subordination process is transparent and does not impact the users of the hierarchy; they can correctly process the certificates issued by the new CA without any configuration changes. Integrating an existing, foreign CA into a hierarchical PKI, however, is more problematic. Subordinating the foreign CA changes the relative point of trust for the users of the foreign PKI. They must now directly trust the root CA of the other PKI hierarchy instead of their own, which may be difficult to achieve in a peer-to-peer business relationship. The most effective way to integrate a foreign hierarchical PKI is for each member user to directly trust the foreign CA-in a secure manner-in addition to its own CA. Care must be taken to limit the use of the foreign CA to the intended purposes only, however. Windows 2000 provides certificate trust lists to disseminate such trust relationships; the section Certificate Trust Lists explains CTLs.

Rooted hierarchical trust models offer a scalable, easy-to-administer PKI because each CA serves a specific role in the hierarchy: as either a root CA or a subordinate CA.

Figure 4-2 A rooted hierarchical PKI

Each member CA processes enrollment requests, issues certificates, and maintains revocation information for its own jurisdiction. Most important, client applications do not need to access a global repository of CA certificates to verify certificate chains. The self-signed root is the natural point of trust, making it straightforward to establish trust in a given certificate, especially when client applications submit complete certifi-cate chains. Secure e-mail applications based on S/MIME and Web browsers belong to this category of applications.

The Network Trust Model

In a network trust model, all CAs are self-signed, and trust flows through the network via cross-certificates. An end-entity directly trusts the CA closest to it and trusts another CA if its direct CA has cross-certified the foreign CA. Because cross-certification creates a parent-child relationship between two CAs, a networked PKI is also a hierarchical PKI with the distinction that the self-signed root is a subordinate CA in the cross-certifying PKI. Entrust Technologies is perhaps the most widely known PKI vendor that supports the network trust model.⁵ Figure 4-3 shows a sample networked PKI.

Figure 4-3 A networked PKI

The network of Figure 4-3 shows three PKI domains that network with one another through three cross-certificates. The certificate X12 represents a cross-certificate between CA1 and CA2; CA1 is the cross-certifying CA, whereas CA2 is the cross-certified CA. The certificate X21 plays the reverse role of the X12 cer-tificate and allows CA2 to cross-certify CA1. The combination of X12 and X21 cross-certificates creates a bilateral cross-certification between domains D1 and D2. Domains D2 and D3, however, have established a unilateral cross-certification: CA2 has cross-certified CA3 but not vice versa. Bilateral cross-certification offers better interoperability behavior than does unilateral cross-certification. Members of domain D1 and D2 can exchange secure, authenticated e-mail, for example, whereas members of domain D3 can send authenticated e-mail to members in domain D2 but will have trouble receiving authenticated e-mail from them.

A new CA enters a networked PKI through the process of cross-certification, in which an existing CA issues a cross-certificate for the new CA. An existing CA leaves the network by revoking its cross-certificate. The cross-certification process is transparent and does not impact the users of the network, provided that they can retrieve the cross-certificates from a global directory. The cross-certification process can also integrate an existing, foreign CA into a networked PKI without changing the relative point of trust for either PKI. Compared to the hierarchical trust model, the network trust model might better represent peer-to-peer business relationships whereby peers develop trust in each other through cross-certification instead of subordination.

The network trust model requires a globally accessible directory to distribute cross-certificates to PKI clients. Without a global directory, a PKI client cannot generally find the cross-certificates necessary to chain the certificate of a communicating peer to the CA that it trusts, causing the certificate verification process to fail. Note that a networked peer typically sends its certificate and the certificate of its own CA only when it communicates with another peer, which may have a different direct CA.

In the network of Figure 4-3, for example, a client of CA1 submits its certificate and the self-signed CA1 certificate when sending a secure S/MIME e-mail or an SSL message to a client of CA3. Clients of CA3, however, do not generally have local access to all the cross-certificates and must contact a global directory to build a proper certificate chain to their issuing CA.

The requirement for an on-line, globally accessible directory of cross-certificates introduces interoperability issues if a client cannot access the directory or if the directory does not contain an up-to-date list of cross-certificates. Furthermore, PKI clients may require application plug-ins because, in general, they do not know how to access a global directory and process cross-certificates. The distribution process of such plug-ins to all clients in a large network, especially an extranet, can become a deployment issue.

The Hybrid Trust Model

The hybrid trust model enables a rooted, hierarchical PKI to interoperate with a networked PKI. The network CAs must cross-certify with the hierarchy root CA; all the clients in the hierarchical PKI must add the network CAs to their list of trusted CAs. Baltimore Technologies is perhaps the most widely known PKI vendor that supports the hybrid trust model.

Certificate Chain Building

A certificate-based application must be able to chain a client's certificate to one of its trust points, typically a trusted, self-signed root CA, in order to verify the certificate and to develop trust in the claimed identity of the client. Some protocols, such as S/MIME and SSL, deliver complete certificate chains to their communicating parties, simplifying the certificate verification task. An application that does not receive a complete chain must build a chain of certificates between the end-entity certificate and a trust point.

Certificate chain building can be bottom-up or top-down. With bottom-up chain building, an application starts with an end-entity certificate and uses the information in the certificate to locate a parent certificate, iterating the process until reaching a trusted root. The bottom-up chain-building process is more efficient than the top-down approach and supports both off-line and on-line, dynamic certificate chain building. Rooted hierarchical PKIs typically use the bottom-up approach for discovering a certification path. Internet Explorer (IE), Internet Information Services (IIS), Outlook, and other CryptoAPI-based applications, for example, build bottom-up certificate chains.

With top-down chain building, an application starts with its directly trusted root CA and finds all the associated cross-certified CAs,repeating the process until find-ing the parent CA of the end-entity certificate. The application needs to access a global directory to retrieve the cross-certificates, unless it has local access to all of them. Networked PKIs generally use the top-down approach for certificate path discovery.

Windows 2000 builds a bottom-up certificate chain from an end-entity certificate up to a trusted CA root, as follows. (Refer to Chapter 3 for a description of the certifi-cate extensions referenced.)

1. If the communicating application does not deliver a trusted certificate chain, Windows 2000 uses the authority key identifier (AKI) extension, if present, to find the parent certificate on the local computer. If the AKI extension contains both the key identifier field and the certificate issuer and serial number fields, Windows 2000 uses the issuer and serial number information first.

2. If it does not find a parent certificate on the local computer, based on the AKI information, Windows 2000 uses the location information in the authority information access (AIA) extension, if present, to retrieve the parent certificate from the network over HTTP, LDAP, or other transport protocols.

3. If steps 1 or 2 do not locate a parent certificate, Windows 2000 uses the issuer name information in a certificate to find a parent certificate on the local computer that has a matching subject name.

Revocation Status Checking

Windows 2000 supports certificate revocation lists (CRLs) as the primary mechanism for revocation status checking. Windows 2000 PKI uses locally cached CRLs; if it cannot find a suitable CRL or if the cached CRL has expired, Windows 2000 PKI dynamically obtains an up-to-date CRL over the network, using a variety of access protocols, such as LDAP, HTTP, and FILE. Windows 2000 uses the CRL distribution point extension for the on-line retrieval of CRLs; it does not support partitioned CRLs and fails revocation status checking.

Windows 2000 PKI does not support the Online Certificate Status Protocol (OCSP) [MYER99] for on-line revocation status checking, does not recognize authority revocation lists (ARLs), and expects a CRL to contain revocation information for both end-entities and certification authorities. An ARL is a special kind of CRL that contains revocation information for CAs only.

Cryptographic Algorithms and Key Lengths

Windows 2000 delivers two CSPs to implement the underlying capabilities of CryptoAPI: a base CSP and an enhanced CSP. Table 4-1 lists the various algorithms and key lengths supported by these two CSPs.

The Microsoft Enhanced CSP is available to all countries worldwide, except to U.S.-embargoed destinations. In addition to the export controls imposed by Microsoft, other countries may exercise separate jurisdictions over the import, export, or use of encryption products. Refer to [http://www.microsoft.com/exporting] for the most up-to-date information on the export control status of Microsoft products.

Table 4-1 Windows 2000-Supported Algorithms and Key Lengths

Hardware Support

Windows 2000 uses CryptoAPI to provide an abstraction layer between applications and key stores. Software-based CSPs manage keys in software, whereas hardware-based CSPs use hardware tokens, such as smart cards, to store and to manage keys. Applications determine the required quality of protection for keys and choose appropriate CSPs.

Windows 2000 uses the PC/SC standard to interface with smart cards and smart card readers. This standard supports plug-and-play and power management features, which are essential to the Windows 2000 environment. Microsoft has no plans to add support for the PKCS #11 standard, which is an alternative protocol for communication with hardware devices.

Certificate Trust Lists

A certificate trust list (CTL) is a list of hashes of CA root certificates, digitally signed by a trusted administrator. A CTL has a validity period and contains restrictions that limit the scope of trust that a given CA has. CTLs provide a convenient, secure mechanism to distribute CA roots to PKI client applications. CTLs are useful in extranet scenarios in which an enterprise needs to establish a trust relationship with a partner without requiring the creation and management of cross-certificates.

Public Key Infrastructure Standards

Windows 2000 adheres to standards set forth by the International Telecommunication Union (ITU) and Internet Engineering Task Force (IETF) standards bodies to ensure maximum interoperability with third-party PKI vendors and service providers. These standards include X.509 V3 for public key certificates, CRL V2 for revocation information, TLS 1.0/SSL 3.0 for Internet security, and Kerberos V5 for network domain authentication. Table 4-2 lists the supported PKI standards.

Table 4-2 Windows 2000 PKI Standards

Interoperability with Third-Party PKIs

Scalability and distributability are perhaps the biggest added-value propositions of a PKI-based authentication system. Using the Internet and PKIs as the backbone, millions of consumers around the globe authenticate hundreds of thousands of Web sites to conduct business-to-consumer processes. Similarly, business partners authenticate themselves to extranets for business-to-business functions. To PKI-enable the Internet, commercial third-party CA service providers supply outsourced trust services, third-party PKI product vendors deliver in-house solutions, and some operating system vendors provide built-in PKI support. To interconnect the maze of resulting trust paths, interoperability among disparate PKIs and PKI-enabled applications becomes critical.

We identify PKI-to-PKI, PKI-to-application, and application-to-application as three levels of interoperability. PKI-to-PKI interoperability allows a PKI system to transparently exchange authentication information with another PKI system. For example, a user in one PKI hierarchy can authenticate a user in another PKI hierarchy, regardless of the specific trust models. PKI-to-application interoperability enables a PKI system to support applications designed for another PKI system, such as the Windows 2000 EFS application. Application-to-application interop-erability addresses how two applications that conform to a standard can interoper-ate, regardless of their specific PKI environments. Interoperability issues between S/MIME e-mail applications and Web browsers to Web servers are examples.

Standards lay the groundwork for interoperability. Standards, however, are subject to various levels of conformance and interpretations, which results in interoper-ability issues. The RFC 2459 standard [HOUS99], for example, profiles the issuing distribution point (IDP) as a critical CRL extension that identifies the CRL distribution point for a particular CRL. The standard does not mandate that a vendor support this extension in order to be compliant.⁶ Unsupported critical extensions, however, cause interoperability issues because an application that does not understand a critical extension must reject the certificate for integrity reasons; it cannot simply ignore it.

Although the RFC 2459 standard does provide a foundation for interoperability, we do not expect conforming PKI systems to have PKI-to-PKI interoperability. We do, however, expect to see a high level of interoperability across vertical applications-application-to-application interoperability-such as S/MIME and TLS/SSL, especially as vendors deploy their applications, gain experience on interoperability issues, and feed their findings back into standards. PKI-to-application interoperabil-ity is making headway as PKI vendors and application providers work out the integration issues.

PKI to PKI

A number of consumer scenarios require two PKIs to interoperate. A very large enterprise may be operating two or more PKIs supplied by different vendors across its organizational boundaries. The enterprise management now wishes to centralize its PKI operation and to provide PKI interoperability among its organizations. Company mergers may also necessitate PKI-to-PKI interoperability if two companies are running different PKI systems. Another scenario involves an enterprise that has and wants to upgrade an existing PKI to Windows 2000. The enterprise wishes to continue using the existing third-party PKI and also wants to leverage the built-in Windows 2000 PKI for a specialized purpose. In another, similar scenario, PKI-to-PKI interoperability issues surface when an enterprise that is using Windows 2000 PKI wishes to deploy a third-party PKI for a specialized use.

Numerous factors impact the interoperability of Windows 2000 PKI with a third-party PKI and ultimately PKI-to-application and application-to-application interoper-ability [MICR00C]. Some factors, such as the lack of a common trust model, have widespread impact and prevent proper authentication between two systems. Such factors as key import and export issues cause administrative overheads and some usability issues, but they do not cripple the entire system.

Trust Model

Windows 2000 supports the rooted hierarchical trust model. A third-party PKI designed around the network trust model faces fundamental PKI-to-PKI interoper-ability issues. Users in the network community cannot authenticate the users in the hierarchical community, because they do not have the necessary cross-certificates. The hierarchical community users fail to authenticate the network community users because they cannot construct a trust path to their trusted CAs. No quick solution exists to fix these problems; the third-party PKI needs to support the rooted hierarchical trust model in addition to its native network trust model.

Global Directory

The operation of a global directory is central to some third-party PKIs, especially those designed around the network trust model. The directory supplies CRLs and cross-certificates to the PKI clients, without which the PKI system cannot function. Windows 2000 PKI can make heavy use of Active Directory as the central data repository but does not depend on a global directory for proper functioning. Windows 2000 PKI can access CRLs and CA certificates from local caches or can retrieve them over the network by using appropriate certificate extension fields. Similarly, the Windows 2000 Certificate Services can work either in standalone mode, without Active Directory, or enterprise mode, requiring Active Directory.

PKIs that depend on a global directory do not necessary have interoperability issues with the Windows 2000 PKI. Active Directory is an integral part of Windows 2000 architecture and runs on every domain controller. The relevant issue is whether a third-party PKI can leverage Active Directory as the underling global repository or must install its own directory. A third-party PKI that requires its own global directory forces an enterprise to deploy and to manage a foreign directory in addition to its native Active Directory, causing administrative overheads and data synchronization issues.

Revocation Status Checking

When it checks a certificate chain for revocation information, the Windows 2000 PKI needs to access an up-to-date CRL for each certificate in the chain. If an appropriate CRL is not available on the local computer, Windows 2000 uses the uniform resource identifier (URI) in the CRL distribution points (CDP) extension to dynamically retrieve the CRL. A third-party PKI that provides a value other than a URI in the CDP extension cannot interoperate with Windows 2000 PKI. Furthermore, vendors that do not support this extension may face interoperability issues unless client computers are synchronized with appropriate CRLs before Windows 2000 begins the revocation checking process.

The IETF RFC 2459 standard profiles the issuer distribution point (IDP) as a critical CRL extension, which identifies the CRL distribution point for a particular CRL. Windows 2000 PKI does not support critical CRL extensions and rejects CRLs that have the IDP extension set.⁷ PKI vendors that use the IDP extension with their CRLs have interoperability issues with the Windows 2000 PKI.

Cryptographic Keys

The level of support a PKI provides for key migration across disparate PKIs and the assumptions a PKI makes about the number of keys an end-entity must possess for correct functions impact PKI-to-PKI interoperability and usability. The main areas of concern are (1) support for exporting and importing keys and (2) single versus dual key use.

It is desirable for users to have the same keys for an application that spans multiple PKIs. PKIs that do not support key import and export force their users to maintain multiple keys for an application, causing administrative overheads and potential security weaknesses. Windows 2000 supports the PKCS #12 standard for secure import and export of keys among PKIs, applications, and computer systems. Third-party PKI vendors that do not support PKCS #12 cannot migrate keys to or from the Windows 2000 PKI.

Windows 2000 PKI does not mandate whether an end-entity should have one certificate good for both signing and encryption or two separate certificates, one for signing and the other for encryption. The issues surrounding dual key pair versus single key pair invariably boil down to key escrow and key life-cycle management requirements. Windows 2000 supports both single key pair and dual key pair policies, allowing enterprises to determine their own policies on these issues.

Third-party PKI vendors that do not provide the same level of flexibility may run into PKI-to-application interoperability issues with Windows 2000 applications. Consider an S/MIME e-mail application, for example, that is designed or configured to work with single key pair certificates. When it receives an authenticated e-mail, this application can use the same certificate that signed the e-mail to send an encrypted e-mail to the sender. If a third-party PKI requires separate signing and encryption cer-tificates, the S/MIME application can no loner use the signing certificate for sending an encrypted e-mail but must now find an appropriate encryption certificate, using another mechanism, such as a directory lookup.

Certificate Handling and Extensions

Similar to the cryptographic keys, two PKI systems with different certificate-handling capabilities may have interoperability issues. A PKI system that does not support Unicode name encoding, for example, may crash when it processes certificates with international names encoded in the Unicode format. Different design assumptions about certificate extensions and the presence of critical extensions in certificates cause major interoperability issues.

Windows 2000 PKI supports the Unicode format and can process certificates that have Unicode names in their subject, issuer, or subject alternative name fields. PKIs that do not support the Unicode name encoding or provide limited support face interoperability issues with Windows 2000 PKI.

Following is a list of certificate extensions and CRL extensions that have a widespread impact on interoperability. Note that although the subject alternative name and extended key usage extensions are more relevant to application-to-application interoperability, we present them here for structural reasons. Refer to Chapter 3 for an explanation of these extensions.

• The authority information access (AIA) extension indicates where to access information about the CA that has issued a certificate. This extension contains location information in the URL format, using various access methods, such LDAP, HTTP, and FILE. Multiple URLs in the AIA extension provide a level of fault tolerance.
  
  CryptoAPI may access the AIA extension during the dynamic chain-building process to retrieve parent CA certificates. The AIA extension is useful for Inter-net or extranet PKI deployments in which PKI clients may not have access to all the CA certificates and cannot access a central directory to retrieve them. The AIA extension provides an alternative approach whereby a PKI dynamically fetches parent certificates over a transport protocol. Third-party PKI vendors that do not populate the AIA extension limit the functionality of CryptoAPI and may cause a failure during the certificate chain-building process.

• Windows 2000 PKI uses the authority key identifier (AKI) extension during the chain-building process, as described in the section Certificate Chain Building. This extension provides key identifier, as well as serial and issuer information about the CA that has issued a certificate. Third-party PKI vendors that do not populate the AKI extension limit the functionality of Windows 2000 PKI.

• The CRL distribution points (CDP) extension indicates how to obtain revocation information for a certificate. Windows 2000 PKI looks up the value of this extension if it cannot find an up-to-date CRL on the local computer during revocation checking. Note that CRLs have validity periods and become obsolete after their end dates. This extension allows CryptoAPI to obtain a valid CRL over the network, using a variety of access protocols, such as LDAP, HTTP, and FILE.

• The CDP extension is extremely useful when a PKI needs to operate across organizational boundaries, when a central administration cannot synchronize client computers with the latest CRLs. PKI vendors that do not populate the CDP extension cause failures when Windows 2000 applications cannot find a valid CRL on the local computer during revocation checking. Furthermore, Windows 2000 PKI does not support X.500 distinguished names in the CDP extension and rejects certificates with such names in the CDP extension.

• The basic constraints extension indicates whether a certificate is an end-entity certificate or a CA certificate. Windows 2000 PKI checks this extension to ensure that an end-entity does not act as CA. Third-party PKIs that do not set this extension in their CA certificates cannot interoperate with the Window 2000 PKI.

• The subject alternative name contains additional name information about the subject name specified in a certificate, such as e-mail name, domain name system (DNS) name, and user principal name (UPN). Some applications, such as S/MIME and IPsec, may not function correctly without this extension. Windows 2000 populates the subject alternative name field when issuing S/MIME and IPsec certificates. PKI vendors that do not populate this extension cause application-to-application interoperability issues.

• The extended key usage (EKU) extension provides further information for the valid use of a certificate and further constraints on the key usage extension. This extension, if marked critical, specifies that a CA has issued a certificate for a particular purpose and that a relying party should not accept it for other purposes. Applications should check the EKU extension and reject certificates that are not valid for a particular function. An S/MIME application, for example, should reject certificates that are issued for File System Encryption (FES) only.

• Certificates that do not contain the EKU extension do not typically cause interoperability problems unless a relying application is especially careful and strictly enforces the right usage of certificates, perhaps to meet special integrity requirements. A certificate that does not contain the EKU extension is valid for all usage as specified by the key usage extension. Windows 2000 supports the EKU extension and uses it to select an appropriate certificate when a user has a number of certificates.

PKI to Application

PKI-to-application interoperability deals with the ability of a PKI system to support applications designed to work with another PKI system. The customer scenarios discussed in the previous section may also require PKI-to-application interoperabil-ity. A large enterprise that is running various PKI systems across its organizational boundaries may want to standardize on one PKI system that supports all its certificate-using applications. Similarly, a merger between two companies may require one PKI system to provide public key capabilities to both companies for all applications. Companies that are upgrading to Windows 2000 face similar issues if they are already using another PKI system.

PKI-to-application interoperability with Windows 2000 PKI involves issues about the ability of a third-party PKI to support certificate-using applications in Windows 2000 and the ability of the Windows 2000 PKI to support third-party certificate-using applications. This section focuses on the more practical case of an enterprise that wants to use a third-party PKI in a Windows 2000 environment exclusively; it is less likely that an enterprise wants the Windows 2000 PKI to run specialized, third-party PKI applications.

Windows 2000 applications have various levels of interoperability with a third-party PKI. Some applications, such as secure Web and secure e-mail, score at the top of the interoperability spectrum, whereas some other applications, such as EFS and smart card log-on, face a number of interoperability issues.

Secure Web

Third-party PKIs have been issuing SSL server certificates for Microsoft Internet Information Services (IIS) for a number of years now and can continue to do so; there should be no interoperability issues with the Windows 2000 IIS. Windows 2000 embeds the root certificates of more than 100 commercial third-party CAs, representing more than 20 countries. These root certificates are enabled for server authentication by default. Among all the certificate-based applications, Web servers have probably the best level of interoperability with third-party PKIs and browsers, across various deployment scenarios. Furthermore, third-party PKIs can issue client certificates for Web access control without any interoperability issues.

Possible interoperability issues center on certificate revocation checking and a rather strange problem with TLS/SSL client-side authentication. As already mentioned, Windows 2000 PKI does not support critical extensions on CRLs, specifically the issuer distribution point extension. IIS and Internet Explorer fail revocation status checking if a CRL contains a critical extension and reject a certificate that might otherwise be valid.

Windows 2000 does not enable client authentication by default for all the pre-configured commercial CAs. Some TLS/SSL implementations have interoperability issues when the list of CAs trusted for client authentication is long and fragments over multiple network packets. These implementations cannot handle the fragmentation and fail the TLS/SSL handshake protocol. An enterprise that uses client cer-tificates for Web access control needs to ensure that the issuing CA is enabled for client authentication.

Secure E-Mail

Similar to the secure Web servers and browsers, secure e-mail applications based on S/MIME are highly interoperable across various PKIs and deployment configura-tions. Windows 2000 enables the preconfigured list of trusted commercial CAs for secure e-mail by default. Interoperability issues may arise, however, if a PKI does not populate the alternative subject name extension, does not support the Unicode name format, cannot handle large RSA keys, or mandates the presence of CA certifi-cates in a global directory. Furthermore, critical extensions on CRLs introduce inter-operability issues with Windows 2000 Outlook and Outlook Express.

Encrypting File System

A third-party PKI can issue certificates for Windows 2000 EFS application under the following two conditions. First, it must populate the EKU extension to indicate that the issued certificate is valid for EFS. Second, it must use the Microsoft Base Cryptographic Service Provider (CSP) to manage the keying material. A third-party CA can either directly generate the key pair on the Microsoft Base CSP or use PKCS #12 to import the key pair to the Microsoft Base CSP.

Windows 2000 PKI seamlessly integrates EFS within the operating system. EFS automatically obtains an EFS certificate for a user from a Windows 2000 CA, if present, or issues its own self-signed certificate. EFS will not automatically interface with a third-party CA to issue EFS certificates for users.

Certificate Mapping

Windows 2000 certificate mapping allows an enterprise to use the Internet for expanding its reach to its business partners, suppliers, customers, and the general Internet public. The enterprise defines a mapping between a certificate and a Windows 2000 account by creating a mapping entry in either the Internet Information Services or Active Directory. Distributed partners use their certificates to access extranet resources, subject to Windows 2000 access-control verifications. Certificate mapping works with certificates issued by any third-party PKI.

Machine Autoenrollment

Computers running Windows 2000 can automatically enroll for certificates against a Windows 2000 Certificate Services enterprise CA. The machine autoenrollment feature does not work with third-party PKIs. A third-party CA, however, can be the parent CA of a Windows 2000 CA that issues machine certificates, as explained in Chapters 5 and 9.

Smart Card Log-On

Windows 2000 leverages the public key extensions of Kerberos to enable smart card-based interactive log-on to a domain network, as described in Chapter 2. A smart card used for network log-on must contain a certificate issued by a Windows 2000 Certificate Services enterprise CA. Windows 2000 rejects certificates that are issued by any other CA. The requirement to have a Windows 2000 CA as the certifi-cation authority for smart card certificates prevents an attacker from breaking into another company's network by using a foreign PKI. Although a third-party CA cannot issue log-on smart card certificates, it can be the parent CA of a Windows 2000 CA that issues such certificates.

Application to Application

A PKI system provides public key capabilities to applications. PKI-to-PKI and PKI-to-application interoperability issues ultimately determine whether two applications, possibly running across different organization boundaries with different underlying PKI systems, can communicate according to the intended design principles and integrity parameters. The capabilities of a PKI for supporting various cryptographic algorithms and cryptographic strengths influence application-to-application interop-erability.The correct functioning of an application may also hinge on certain certificate extensions, such as the subject alternative name extension, as discussed previously.

The cryptographic algorithms and the key lengths supported by a PKI can directly impact application-to-application interoperability. Windows 2000 uses CryptoAPI in conjunction with the underlying Microsoft Base and Microsoft Enhanced CSPs to provide cryptographic capabilities to applications. Similarly, other third-party PKI vendors provide an engine to provide such capacities to their applications. Applications will fail to interoperate if they cannot negotiate a common encryption algorithm and key length, using such protocols as TLS/SSL. Similarly, store-and-forward applications, such as e-mail, may fail if a sender and a receiver use PKIs with different capabilities. An e-mail application that has low-strength cryptographic capabilities, for example, cannot decrypt an e-mail encrypted with triple DES.⁸

---

5. Entrust plans to support the hierarchical trust model in the 5.0 release of its products.

6. We must emphasize that the RFC 2459 standard attempts to solve a fairly general problem and needs to be broad in nature.

7. Note that implementations conforming to RFC 2459 [HOUS99] need not support the IDP extension.

8. It should be noted that Microsoft Mail applications, both the original Exchange Mail client and Outlook, are able to decrypt all strengths of encryption; the only issue is at what level they are able to encrypt messages. This capability removes this issue as a problem for Microsoft Mail applications. We thank Christopher Lowde for this clarification.