Public Key Interoperability

Public key is an enabling technology for customers extending their business model to the Internet where strong distributed authentication and secure communications are critical to facilitating business-to-business and business-to-consumer scenarios. Now that the Microsoft® Windows® 2000 operating system includes a standards-based public key infrastructure (PKI) that is interoperable with other PKI products, customers can deploy an integrated PKI as part of their server and desktop infrastructure and manage it in the same way they manage other Windows 2000 security features.

On This Page

Introduction Scenarios Entrust Netscape Baltimore Technologies Commercial CAs Trust Models Keys and certificates Supported Standards Additional References

Introduction

Public key is an enabling technology for customers extending their business model to the Internet where strong distributed authentication and secure communications are critical to facilitating business-to-business and business-to-consumer scenarios. Now that the Microsoft® Windows® 2000 operating system includes a standards-based public key infrastructure (PKI) that is interoperable with other PKI products, customers can deploy an integrated PKI as part of their server and desktop infrastructure; and manage it in the same way they manage other Windows 2000 security features.

The goal of this paper is to describe how the Windows 2000 PKI interoperates with other certificate-based PKI products from Netscape, Entrust, Baltimore, and commercial certification authorities (CAs) like Belgacom, Digital Signature Trust, Entrust.net, GlobalSign, GTE CyberTrust, TC Trustcenter, Thawte, VeriSign, and others. This paper assumes that the reader is somewhat familiar with public key technologies and its uses. The focus in this paper will be on common operations performed by administrators and users of a PKI such as CA trust, certificate enrollment, certification path validation, revocation status checking, and the use of public key-enabled applications like secure web authentication and secure e-mail.

Microsoft's Goals

Microsoft's primary motivation for integrating public key services in Windows 2000 was to enable the platform for future e-business opportunities. This meant providing distributed authentication services based on Internet standard protocols like Kerberos version 5, Secure Sockets Layer (SSL), Transport Layer Security (TLS), and IP Security. Integrating public key services with Windows 2000 also meant taking advantage of the Active Directory™ service and the security infrastructure provided by the operating system to keep ownership costs down by making management of a PKI as transparent as possible. Likewise, implementation of established Internet standards was an important requirement to achieve interoperability with other standards-based PKI products.

Standards

Standards are the basis for achieving interoperability between products from different vendors. To achieve PKI interoperability, Microsoft actively works with other vendors and participates in industry-sponsored testing events. Microsoft has been and continues to be involved with standards organizations like the Internet Engineering Task Force (IETF), International Telecommunications Union (ITU), and government agencies like the National Institute of Standards and Technology (NIST) in the United States to help define PKI standards. Microsoft will continue to incorporate new standards into its products in order to make interoperability a key feature of the Windows platform.

Scenarios

Customers will find that Windows 2000 interoperates well with PKI products from other vendors. There are two major scenarios involving Windows 2000 and third-party PKIs. The first scenario concerns using both the Windows 2000 PKI and a third-party PKI in a Windows 2000 environment; and the second scenario involves using a third-party PKI exclusively in a Windows 2000 environment.

Third-party PKI with Windows 2000 PKI

This scenario involves use of both the Windows 2000 PKI and a third-party PKI. The scenario includes customers with an existing third-party PKI who have upgraded to Windows 2000 and then deployed the Windows 2000 PKI for specific applications such as secure web access. The scenario also includes customers who have deployed the Windows 2000 PKI and then a third-party PKI for specialized purposes. Before discussing each third-party PKI product and its interoperability with Windows 2000, those features of Windows 2000 that can also be used with third-party PKI products will be identified.

Encrypting File System

A third-party CA should be able to issue certificates for use by the encrypting file system (EFS) if the certificate contains the enhanced key usage extension for EFS and the Microsoft RSA Base cryptographic service provider (CSP) is used to manage the associated private key. Using a certificate issued by a third-party CA can be accomplished either by using the Microsoft RSA Base CSP to generate the public/private key pair or by importing the certificate and private key using the Public Key Cryptography Standards #12 (PKCS#12) file format.

Certificate Mapping

Certificate mapping is a Windows 2000 feature where a certificate issued by a third-party CA can be associated with a Windows 2000 user account stored in Active Directory. Software such as Microsoft Internet Explorer and Internet Information Services (IIS) can be used to authenticate a user (connecting to a Web server over the public Internet using a protocol like Secure Sockets Layer) to an account stored in Active Directory based on name information in a certificate.

The account that the certificate maps to is used to determine the user's access rights on the server. This is an extremely powerful feature for Web-based applications and third-party CAs because it combines strong authentication using public key technology with the native authorization model of Windows 2000. 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 to map them to accounts in the Active Directory service.

Trusted CA Root Policy

Trust of a third-party CA can be established using Group Policy. An administrator can specify CA trust for collections of computers and users and apply that policy without having to configure each computer individually. A third-party CA root certificate can be automatically distributed to all computers and users in a domain, site, or organizational unit (OU) to support both outsourced PKIs as well as extranet scenarios.

Certificate Trust Lists

Certificate Trust Lists (CTLs) are used to certify other PKIs without requiring the creation and management of cross-certificates. A CTL is simply a list of hashes of CA root certificates that is digitally signed by a trusted administrator. CTLs are created and applied using Group Policy and have two additional properties that make them useful in extranet scenarios. First, CTLs have validity periods and CTLs have usages that limit the purposes for which a given CA is trusted. Hence, CTLs make it possible to establish a trust relationship with a partner or customer based on the other company's CA certificate without having to issue certificates to the other company's employees and without having to change application behavior.

Third-party PKI without the Windows 2000 PKI

In this scenario the customer is exclusively using a PKI other than the integrated PKI provided with Windows 2000. This includes customers with an existing third-party PKI wishing to upgrade their computing environment to Windows 2000 as well as customers wishing to install a new third-party PKI in an existing Windows 2000 domain environment.

Customers should contact their PKI vendor for information on how its products work with Windows 2000. Third-party products can receive a Windows 2000-compatible logo to signify how well it interoperates with Windows 2000 features including Active Directory and the security infrastructure.

Microsoft has tried to ensure that applications that worked with the Windows NT® 4.0 operating system continue to function on Windows 2000. If a customer has already deployed a PKI from another vendor such as Entrust, Netscape, Baltimore Technologies, or a commercial CA, then the customer should be able to continue to use that PKI without losing functionality.

For example, public key applications using Secure Sockets Layer (SSL) or secure e-mail will still work on Windows 2000 with a third-party PKI. However, there are some new features in Windows 2000 that will not be available if the Windows 2000 PKI is not used.

Machine Auto-Enrollment

Windows 2000 provides the ability for Windows 2000-based computers to automatically enroll for certificates. The ability to automatically enroll and renew machine certificates lowers the cost of managing a PKI because administrators do not need to manually enroll machines for certificates and keys. The auto-enrollment feature is enabled using Group Policy and only works with the Windows 2000 Enterprise CA published in Active Directory. While a third party CA cannot be the issuing CA for auto-enrollment, it can be a parent CA of a Windows 2000 issuing CA.

Management Tools

Windows 2000 includes a number of tools for managing the Windows 2000 PKI. The tools are implemented as Microsoft Management Console (MMC) snap-ins that provide users and administrators the ability to manage certificates and keys throughout the enterprise. These tools can be used to view and manage certificates for any Windows 2000 CA, publish information to the Active Directory service, establish trust relationships, create policies, and enroll users and computers for certificates. These tools cannot be used to manage third-party PKI products.

Roaming Profiles

Because Windows 2000 stores user certificates and keys in the user's profile in an encrypted form, a user with a roaming profile (not a mandatory profile which is read-only) will have access to his or her personal certificates and keys anywhere within a Windows 2000 domain environment. Applications that use CryptoAPI to manage their certificates and keys will be able to use this Windows 2000 feature automatically without having to add any code. Applications that do not use CryptoAPI will need to provide their own mechanism of roaming certificates and keys between systems.

Smart Card Logon

Smart card logon is integrated with the Kerberos version 5 protocol implemented in Windows 2000, as specified by IETF RFC 1510 and its public key extension PKINIT. Smart card logon uses the Windows 2000 GINA (Graphical IdeNtification and Authentication) known as the logon user interface, so replacing the GINA with a third-party GINA would remove support for smart card logon.

In addition, the issuing CA of a smart card logon certificate must be a Windows 2000 Enterprise CA published in Active Directory for the domain. This requirement exists to prevent name-spoofing attacks by foreign PKIs trying to gain entry into another company's network. By requiring information about the issuing CA to be published to Active Directory in a specific location, the Windows 2000 domain controller can trust that the CA is authoritative in the domain's namespace.

While the issuing CA for smart card logon must be a Windows 2000 Enterprise CA, third-party CAs can be the parent or root CA.

Encrypting File System

The encrypting file system (EFS) in Windows 2000 requires the Windows NT file system (NTFS) and the Microsoft RSA Base cryptographic service provider (CSP). EFS will automatically enroll the user for an EFS certificate from a Windows 2000 CA, if one is present, or it will generate its own self-signed certificates. EFS will not automatically enroll against a third-party CA.

Entrust

The Windows 2000 PKI is different in three ways from the Entrust PKI. First, the Windows 2000 PKI is based on a rooted hierarchical trust model while Entrust 4.0 uses a network trust model. Why this is important to interoperability will be described later in this paper when discussing Trust Models. Second, an Entrust PKI requires an LDAP directory to store CA information and its CAs must be available (for example, online) to maintain up-to-date certificate revocation lists and to provide certificate lifecycle management. While the Windows 2000 PKI takes advantage of Active Directory, if it is present, it does not require a directory for a CA to function. Also, Windows 2000 CAs can be offline to increase the level of protection for a CA's private keys. Third, the enterprise configuration of the Entrust PKI assumes that all users have dual key pairs, one for digital signature and the other for encryption. Entrust's connector products may be used to provide alternate models for Web servers and virtual private network (VPN) devices. Windows 2000 PKI supports both dual and single key pairs to ensure maximum interoperability between different PKIs and applications.

Because the next release of the Entrust PKI, referred to as Entrust 5.0, is not yet available for Microsoft to test interoperability with Windows 2000, interoperability testing has only been done with the Entrust 4.0 product. It is expected that interoperability will improve with Entrust's next product release. Note that the following interoperability discussion is based solely on this testing and does not attempt to comment on what might happen in Entrust's upcoming product(s). Microsoft and Entrust will jointly test interoperability of Windows 2000 and Entrust 5.0 and this paper will be updated with those results.

The Entrust 4.0 PKI will continue to work on Windows 2000. However, there will be little, if any, integration with the Windows 2000 PKI because Entrust 4.0 has it's own enrollment protocol, manages its own certificates and keys, and uses an its own LDAP-compliant directory rather than the Windows 2000 LDAP-compliant Active Directory. A customer who has deployed the Entrust 4.0 PKI should contact Entrust about their interoperability strategies and the list of applications that will work with the Entrust PKI deployed in a Windows 2000 domain environment.

Certification Authority

The Windows 2000 certification authority can be a CA in an Entrust PKI if its information is published in the LDAP directory used by Entrust. A Windows 2000 CA will not be trusted unless its CA information is published into the LDAP directory used by Entrust. To establish trust with an Entrust CA, the Entrust CA can either publish its information to Active Directory or its certificate can be added to Group Policy. Because Entrust 4.0 does not make use of the Windows 2000 Active Directory, two separate directories will exist in a Windows 2000 environment where the Entrust PKI is deployed and used by applications.

A Windows 2000 CA can be cross-certified by an Entrust CA. Likewise, an Entrust CA can be certified by a Windows 2000 CA using a certificate trust list, without forcing non-Entrust applications to become Entrust-enabled.

Certificate Enrollment

Certificate enrollment is an area where interoperability is a major concern. The Entrust 4.0 enterprise product uses a different enrollment protocol that prevents applications that are not Entrust-enabled from enrolling to an Entrust CA. The Entrust Web connector product supports PKCS#10 and PKCS#7 messages, and may be used to improve interoperability for enterprise certificate enrollment.

Certificates and Certificate Revocation Lists

Certificates that are issued by the Entrust PKI contain X.500 Distinguished Names (DN) that clients must convert to an LDAP query and send to an appropriate server. While Windows 2000 PKI (and other third-party PKIs) could convert the X.500 DN in the certificate to an LDAP query, there is no way of determining to which server the request should be sent because the Windows 2000 PKI does not assume a global directory.

The Entrust CA produces Certificate Revocation Lists (CRLs) partitioned by the number of certificates issued. The partitioned CRL is designed to limit the maximum size of a CRL. Unfortunately, this is an optional feature in the IETF RFC 2459 standard and most PKIs, including Windows 2000, do not support partitioned CRLs. Because the Entrust PKI makes extensive use of this feature, applications that are not Entrust-enabled will not be able to interoperate when performing revocation status checks because they will not be able to distinguish between the different partitioned CRLs.

Secure Web

The primary interoperability problem with an Entrust PKI and web applications concerns CRL extensions. Entrust supports an optional CRL extension called Issuer Distribution Point and marks it critical, as specified by IETF RFC 2459. When an extension is marked critical and is not supported, the standard specifies that the certificate or CRL where the extension appears must be rejected. Internet Explorer and Internet Information Server will fail a revocation check (using certificates issued by Entrust version 4.0) because Windows 2000 does not support this CRL extension and Entrust marks it critical. While both Entrust and Windows 2000 are compliant to the IETF RFC 2459 standard, this still results in an interoperability problem when one PKI implements an optional feature and another PKI does not.

Secure E-mail

The majority of interoperability issues with Entrust-enabled applications and Windows 2000-based applications have to do with the requirement that a trusted CA be published in the LDAP directory used by Entrust, and that applications know how to access the LDAP directory used by Entrust to validate certificates. These limitations make it difficult to test interoperability between an Entrust PKI and all other e-mail applications that are not Entrust-enabled.

For example, while a Windows 2000 e-mail client like Outlook® Express can receive and successfully process digitally signed or encrypted e-mail messages sent by an Entrust-enabled e-mail application, the reverse is not true because the Entrust-enabled application expects to find the sender's CA in its directory. An Entrust-enabled application will not accept a secure e-mail message from a non-Entrust e-mail application unless the sender's CA is in the Entrust local address book or in the LDAP directory used by Entrust.

Netscape

The Netscape PKI trust model is based on a rooted hierarchy, which is the same trust model that Windows 2000 assumes. The only products that were available to Microsoft for interoperability testing were the Netscape 1.x certificate server product and the Netscape Communicator 4.x browser. The iPlanet alliance between Sun Microsystems and Netscape, now part of AOL, has recently shipped a Certificate Management Server 4.1 product that is based on the original Netscape 1.x certificate server.

Certification Authority

The Netscape CA can be a subordinate or a root to a Windows 2000 CA. Likewise, a Windows 2000 CA can be a root or subordinate to a Netscape CA. Certificates issued by either CA are usable by applications for secure e-mail and secure web access. The certificates issued by the Netscape CA product are X.509 version 3 certificates and are compatible with Windows 2000 features like Internet Explorer and Outlook Express.

Certificate Enrollment

Internet Explorer can enroll with a Netscape CA and install the certificate returned by the Netscape CA. Likewise Netscape applications such as the browser can enroll to a Windows 2000 CA without problems. However, non-Netscape applications enrolling to a Netscape CA need to be aware that Netscape uses a different response message than a PKCS#7 message. If the next version of the Netscape or iPlanet CA supports a PKCS#7 message as the CA response, this interoperability issue will no longer exist.

Certificate Revocation Status Checking

The Netscape CA uses a non-standard revocation checking mechanism that requires an application to access the Netscape CA each time it performs a revocation status check. The Windows 2000 PKI has implemented this feature so that Netscape applications with certificates issued by a Windows 2000 CA can perform revocation status checking without requiring a CRL. The next release of the Netscape and iPlanet certificate server product is expected to support CRLs.

Secure E-mail and Secure Web

In general, interoperability with clients and servers running Windows 2000 and Netscape is good, meaning that Netscape clients and servers can communicate with Windows 2000-based clients and servers using SSL, TLS, and S/MIME. However, there are some limitations such as with revocation checking because Netscape products do not support CRLs. There are also issues with Netscape clients being able to handle large RSA keys (for example, 4096-bit) and Unicode name encoding. For example, the Netscape browser does not currently support international characters. These issues are discussed in more detail later in the paper.

Baltimore Technologies

The Baltimore PKI supports a hybrid trust model where both hierarchies and cross-certificates can be supported. The Baltimore CA product can use a directory but does not require it to function. Currently Microsoft has only done testing with the Baltimore CA and has not evaluated the product when a directory is present. Microsoft has not done any testing with the Baltimore client software or their PKI toolkit.

Certification Authority

The certificates issued by the Baltimore CA product are X.509 version 3 certificates and are compatible with Windows 2000 features like Internet Explorer and Outlook Express. The biggest interoperability problem with the Baltimore CA is that it does not provide a CRL Distribution Point 1 (CDP) extension in the certificates it issues. This means that any application that does revocation status checking will fail unless the CRL is already available locally on the machine. Since Internet Information Server checks revocation status automatically when SSL is enabled, applications using Baltimore certificates will fail.

Commercial CAs

Many commercial CAs, if not all, support a rooted hierarchical trust model that makes them compatible with Windows 2000. Internet Explorer and Outlook Express can use certificates issued by commercial CAs as can Internet Information Server.

Certification Authority

In order to enable Internet protocols like SSL and TLS used by secure Web servers, Microsoft has included the root certificates of established commercial CAs such as Belgacom, Digital Signature Trust, Entrust.net, GlobalSign, GTE CyberTrust, TC Trustcenter, Thawte, VeriSign, and many more. The commercial CA certificates included with Windows 2000 represent more than 20 countries worldwide. CAs can also allow users to install additional root certificates from their public Web sites because Windows 2000 allows users to extend their trust relationships beyond the list of CAs included by default.

Interoperability problems with commercial CAs may arise if their certificates are not X.509 version 3 certificates. This is because the older versions of X.509 certificates do not support required extensions such as Basic Constraints and CDP.

Secure E-mail

The commercial CA certificates pre-configured in Windows 2000 are enabled for secure e-mail by default. This means that users with certificates issued by a commercial CA such as VeriSign or TC TrustCenter will be trusted by e-mail applications that support digital signing and encrypting of e-mail messages. Because each CA operates under different policies and practices, the ability to use a certificate issued by a commercial CA will vary across applications, and in some cases will be affected by information included or not included in a certificate. For example, most e-mail clients require the presence of an e-mail name in the certificate in order to be used for secure e-mail purposes.

Secure Web

The commercial CA certificates pre-configured in Windows 2000 are also enabled for server authentication. Server certificates issued by a commercial CA such as GTE CyberTrust or GlobalSign can be trusted by Internet Explorer and Internet Information Server for establishing a secure communications channel using the SSL or TLS protocols. Server authentication is the most widely deployed application for public key and is used by all major web sites including Amazon.com, Dell, and others.

Client authentication is not enabled by default for all commercial CA certificates included with Windows 2000. This is because there are interoperability issues with SSL and TLS implementations when the list of trusted CAs is long and spans multiple protocol packets. Some implementations cannot handle this fragmentation resulting in failed session negotiations. Because client authentication does not work unless the user has an identity certificate from a CA enabled for this purpose, server administrators should be the ones to enable CAs trusted in the enterprise.

Trust Models

Trust is fundamental to how a PKI operates and is critical to how different PKIs can interoperate. Two types of public key trust models exist where certificates are used to bind identity information to key pairs: rooted hierarchies and network trust hierarchies. Both are considered hierarchies because no matter how one constructs a chain of certificates, there is a parent-child relationship between all certificates in the chain. The difference between the two models tends to be in how the certificate chains are constructed, how they are verified, and where certificate information is stored.

Rooted Hierarchical Trust Model

In a hierarchical trust model, as shown in Figure 1, the root CA is the trust anchor and has a self-signed certificate. Each subordinate CA has a certificate issued by the CA above it, a parent CA. A subordinate CA is trusted cryptographically based on the signature of its parent with the added constraint that the topmost parent be a trusted, self-signed root CA.

Rooted hierarchies are supported in numerous products and services offered by major software vendors including Microsoft, AOL/Netscape, Baltimore, and international commercial CAs. A new CA can be added to a hierarchy by enrolling to a CA anywhere in the hierarchy. If a new hierarchy is created, then trusting the root CA of the new PKI is all that would be required to trust all the subordinate CAs in the new hierarchy.

Figure 1: Rooted Hierarchy Trust Model

Rooted hierarchies are typically deployed with three levels. The CA at the top of a hierarchy is generally referred to as a root CA whose certificate is self-signed. A self-signed certificate is a certificate whose Subject name and Issuer name are the same and whose public key can be used to verify the signature on the certificate itself since no parent certificate exists.

The CA below the root in a three-level hierarchy is referred to as a policy CA (PCA) or intermediate CA. The PCA can be online or offline and is typically used to separate classes of certificates that can be distinguished by policy. Examples of policy separation can be in the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations.

The third-level in a rooted hierarchy contains the issuing CA. The issuing CA, as the name implies, issues certificates to end-entities and is almost always online. End-entities can be computers and users.

Netscape, Baltimore, and Commercial CAs

The vast majority of commercial CAs support a rooted hierarchical model as does Netscape and Baltimore. Each have issued thousands of certificates for secure Web servers, secure e-mail, code signing, and other types of services. Interoperability has already been discussed with respect to each of these PKIs.

Benefits

Hierarchies are more scalable and simpler to administer because each CA serves a single role within a hierarchy and is not operationally dependent on other CAs. Any CA in a hierarchy is either a root or a subordinate but never both. Each CA is responsible for processing requests and issuing certificates signed by its own key; each CA is responsible for revoking certificates and publishing CRLs to accessible locations; and each CA in a hierarchy can be managed separately by different personnel in different parts of an organization to match real-world business scenarios.

Because CAs in a rooted hierarchy can be online or offline, there is a great deal of flexibility in how a PKI can be deployed and managed. The ability for a CA to be offline is critically important because it provides for increased protection of the CA's private key. This is because the CA can be physically secured in a vault or offsite location without having to expose it to the network for any purpose. Physical security is straightforward and does not impact other parts of the hierarchy because offline CAs are typically the root or policy CAs that only issue certificates to other CAs.

Another benefit of rooted hierarchies is that the self-signed root is the natural trust anchor so deciding whether a given certificate can be trusted is straightforward since most protocols like SSL and S/MIME deliver a chain of certificates that terminates in a trusted root CA. Unlike cross-certification hierarchies, there is no need to access some global repository to try and find other certificates outside the natural certificate chain.

Network Trust Model

In a network trust model, as shown in Figure 2, all CAs are self-signed and trust relationships between CAs are based on cross-certificates. Direct trust is between a client and an issuing CA. Additional trust relationships result when the issuing CA has cross-certified with other CAs. A new CA is added to a network of trust by issuing a cross-certificate, and an existing CA is removed from a trust network by revoking its cross-certificate.

Because a cross-certificate is a logical subordination of one CA to another CA, it should be obvious that a network trust model is essentially a hierarchy with the added property that a root CA is also a subordinate CA in the cross-certifying PKI. A network trust model can be viewed as a hierarchy because a cross-certificate is essentially the same as a subordinate CA certificate in a rooted hierarchy. The cross-certifying CA is the Issuer and the cross-certified CA is the Subject. The real difference between a network trust hierarchy and a rooted hierarchy is that in a rooted hierarchy a global directory is not required and in a network trust hierarchy a global directory is essential. Without a global directory, discovery of cross-certificates is not possible without pre-installing them on all clients of the PKI.

Figure 2: Network Hierarchy Trust Model

Certificate X12 represents a cross-certificate between CA1 and CA2 with CA1 being the cross-certifying CA and CA2 being the cross-certified CA. Certificate X21 is the reverse and together they represent a bi-lateral cross-certification. One aspect of network hierarchies often overlooked is that cross certification does not need to be bi-directional and a cross-certifying CA does not need the co-operation of the CA being certified.

For example, it would be quite valid if cross-certificate X21 shown in Figure 2 did not exist. In that case clients of CA1 would trust CA2 and CA3 while clients of CA2 and CA3 would not trust CA1. CA1 accomplished this by creating cross certificate X12 without CA2's knowledge because all that CA1 needs was CA2's public key certificate. This is known a unilateral cross-certification where one CA cross-certifies another CA but not the reverse. Bi-lateral cross certification occurs when two CAs cross-certify each other, meaning both parties are active participants in the cross-certification process. Bi-lateral cross-certification is the more preferred scenario, although it can lead to having to manage many relationships as the number of cross-certificates increase.

Entrust

The most popular PKI product that supports cross-certification is offered by Entrust. The Entrust PKI product includes a directory because one of the biggest problems applications have with cross-certificates is actually finding them. To solve the problem of discoverability, an Entrust PKI requires a globally accessible directory to store cross-certificates. Since not all applications know how to process cross-certificates, an Entrust PKI also requires application plug-ins to enable applications to process cross-certificates in the LDAP directory used by Entrust.

A global directory is critical to network trust hierarchies because protocols like SSL and S/MIME do not include cross-certificates when communicating. For example in Figure 2, a client of CA3 sending a secure e-mail message to a client of CA1 will only include its own certificate and CA3's root certificate (representing what we will call the "natural chain") in the message. The receiving client does not trust CA3 but rather trusts CA1; and because the receiving client would not typically possess all cross-certificates between CA1, CA2 and CA3, it must somehow gain access to a central repository to find and retrieve these additional certificates in order to build a certificate chain to the CA it does trust.

As long as the receiving client can access a directory containing the cross-certificates, this works. Unfortunately, interoperability problems typically occur when access to the directory is not available to both sides of a communication, or not all certificates are available to the receiving application in order to build a valid certificate chain. For example, two companies who are using secure e-mail to communicate would need to synchronize their directories to ensure that users in both companies can discover each other's cross-certificates.

Benefits

The primary appeal of cross-certification is that it enables bridging between separate PKIs without the need for direct subordination of either party. Because cross-certification is an indirect subordination of one PKI to another, the trust point does not change relative to either PKI. This is beneficial because each PKI does not have to be dependent upon the other and can maintain its own autonomy. Bi-lateral cross-certification follows how companies form relationships where each side participates in establishing the relationship.

Certificate Chain Building

Chain building is what occurs when a client verifies a certificate in order to trust it for a particular use. Figure 3 illustrates a certificate chain. The chain starts with an end-entity certificate, followed by a succession of CA certificates where each CA certificate is the parent (Issuer) of the previous certificate (Subject), terminating in a self-signed root certificate.

Figure 3: Certificate Chain

When building a certificate chain, the client can build bottom-up or top-down. With bottom-up chain building, one starts with the end-entity certificate and finds each parent until it terminates in a trusted root. Information contained in each certificate is used to find parent certificates making the chain building process efficient and capable of supporting both offline as well as dynamic certificate chain construction. Bottom-up chain building is typically used with rooted hierarchies. Microsoft applications that use CryptoAPI like Internet Explorer, Internet Information Services (IIS) and Outlook will build certificate chains from the bottom-up.

Alternatively a client may choose to start at a trusted root certificate and build a chain down to an end-entity certificate. This is how Entrust builds certificate chains and is referred to as top-down chain building. In this top-down process the client attempts to find all cross-certificates associated with each CA certificate starting with the self-signed root. This process repeats until a complete chain is constructed from the trusted root down to the end-entity certificate. Top-down chain building is usually used in network trust models and almost always requires a central repository as previously discussed.

Windows 2000 Chain Building Algorithm

The certificate chain building code in Windows 2000 attempts to build a certification path (that is, certificate chain) from the end-entity certificate (for example, a user or computer certificate) up to a trusted CA root as follows:

1. If a trusted certificate chain is not delivered as part of the protocol, Windows 2000 uses the Authority Key Identifier (AKI) field information (if present) to find the parent certificate(s) on the local computer. If AKI contains Issuer and Serial Number information, Windows 2000 will look for a specific parent certificate that matches; otherwise it will use the key identifier value to find matching parent certificate(s).

2. If Windows 2000 does not find all parent certificates in the certificate chain delivered by the protocol, or on the local computer based on AKI, it will then look at the Authority Info Access (AIA) field in the certificates. The Windows 2000 PKI will use location information in AIA (if present) to retrieve the parent certificate(s) from the location(s) specified (for example, HTTP, LDAP).

3. If neither of the above yields all required parent certificates, then the Windows 2000 PKI will use the Issuer name information in a certificate to find a parent certificate containing a matching Subject name on the local computer.

Certificate Discoverability

The Windows 2000 PKI uses location information in the AIA extension of a certificate to retrieve the parent of a certificate if it does not find the parent certificate on the local system. Third party CAs will either need to provide this extension or parent certificates will need to be distributed to domain clients so that the certificates are available before the chain building process begins. Entrust, Netscape, and Baltimore do not provide this extension. Likewise, cross-certificates must also be available locally on domain clients because there is no information in a certificate specifying where they can be found.

Revocation Status Checking

The Microsoft PKI client currently does not process CRLs containing critical extensions. In Windows 2000 a CRL with a critical extension will be rejected as required by the IETF RFC 2459. CRLs issued by Entrust 4.0 must contain the Issuer Distribution Point extension and the extension must be marked critical as specified by RFC 2459. This means that Windows 2000 must fail validation of these CRLs resulting in Entrust 4.0 certificates failing revocation checks.

If an application is requesting that revocation information be checked, then the CRL for each CA in the certificate chain must either be local to the system or a URL must be in the CDP extension. Entrust 4.0 contains a CDP but it does not contain a URL so the revocation check will fail. The Netscape CA does not issue CRLs and it does not include the CDP extension in certificates it issues; therefore, revocation status cannot be checked except through the proprietary Netscape method previously mentioned. Baltimore also does not provide a CDP extension so revocation checking will fail.

Keys and certificates

The Windows 2000 operating system supports the ITU X.509 version 3 and version 1 certificate formats. Windows 2000 supports several well-known cryptographic algorithms also supported by other PKI products. This provides a solid foundation for interoperability because Windows 2000 applications will understand how to process certificates from other PKIs. Likewise, certificates issued by a Windows 2000 CA will be interoperable with third-party PKI products.

Keys

Key management is an important feature of any PKI. The ability to share keys between PKIs is critical to interoperability because users will want to use their same certificates and associated key material across applications regardless of the underlying PKIs. The ability to recover key material used to encrypt and decrypt persisted data is another important feature of a PKI but does not cause interoperability problems because archival and recovery operations are done outside the application context. However, applications are affected by the number of keys required by a PKI because different PKIs can place limits on the usages of different keys. Likewise the length of keys is another source of interoperability problems when different PKIs support different minimum and maximum key lengths.

Dual Key Pair vs Single Key Pair

If a PKI uses public/private keys based on an algorithm such as RSA then all PKI operations can be accomplished with only one key pair. However having only a single key pair is not always desirable which is why Windows 2000 supports both single key pairs and dual key pairs. Netscape also supports single and dual use keys while Entrust and Baltimore require dual use keys. A good PKI will be flexible enough to allow as many or as few key pairs as required by applications.

Interoperability is directly affected when one PKI makes assumptions about the number of keys used by applications. For example, an e-mail application could sign a message with a signature-only key and include the associated certificate in a message sent to a recipient without also sending an encryption certificate as part of the message. The recipient then must be able to discover the sender's encryption certificate, perhaps in some directory, in order to reply with an encrypted message back to the sender.

Key Import and Export

While Microsoft, Netscape, and commercial CAs like VeriSign support key import and export between their PKIs, Entrust and Baltimore do not. This means that keys in an Entrust or Baltimore PKI cannot be migrated between PKIs forcing users to have different keys across applications that span multiple PKIs. Microsoft and Netscape support moving keys between PKIs and applications using the PKCS#12 standard that defines a data format for securely importing and exporting key material to an encrypted file. If Entrust and Baltimore add support for PKCS#12 to their products, then users will be able to use the same keys across applications.

Algorithms and Key Length

Cryptographic algorithms and key lengths are another important PKI feature and can be a source of interoperability problems when PKIs do not support the same algorithms and key lengths. Windows 2000 supports numerous cryptographic algorithms and key lengths as do Entrust, Netscape, Baltimore, and others. Because maximum key length is an attribute controlled by government export (and import) laws, some PKIs will claim support for longer key lengths because they have agreed to support key escrow. Microsoft has not agreed to support key escrow and is therefore not allowed to ship support for longer key lengths outside the United States and Canada. It is expected that restrictions on export of strong cryptographic keys will be eased in the near future without requiring key escrow. When that happens, Microsoft will make that functionality available.

The table below identifies the algorithms supported in Windows 2000 and their minimum and maximum key lengths.

Algorithm	Key Length (United States and Canada)	Key Length (International)
RSA	Min: 384-bit Max: 16,384-bit	Min: 384-bit Max: 16,384-bit
DSA	Min: 512-bit Max: 1,024-bit	Min: 512-bit Max: 1,024-bit
DH	Min: 512-bit Max: 4,096-bit	Min: 512-bit Max: 1,024-bit
RC2, RC4, RC5	Min: 40-bit Max: 128-bit	Min: 40-bit Max: 56-bit
DES40	Min/Max: 40-bit	Min/Max: 40-bit
DES56	Min/Max: 56-bit	Min/Max: 56-bit
3DES	Min/Max: 168-bit	Min/Max: 168-bit

Key length is not an interoperability issue for public/private keys, except when one PKI supports large public key lengths and another does not making it impossible to exchange symmetric keys or sign and verify data. While key exchange and digital signature operations performed between PKIs do not have to use the same public/private key lengths, symmetric key algorithms do require the same size keys to work. When PKIs do not support the same key lengths, some applications will not be able to decrypt data that other applications will be able to decrypt. In addition, the ability to establish secure communications channels between applications will be impacted if applications across different PKIs cannot agree on symmetric key lengths as required by protocols like SSL and TLS.

Hardware Support

An often-overlooked area is hardware-based key support. For increased security, it is always recommended that user and computer keys be stored in hardware devices. A good PKI will interoperate with many different hardware vendors and will provide a hardware abstraction layer to allow applications to not have to know where keys are stored.

Windows 2000 uses CryptoAPI to abstract hardware-based key management from applications and uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Entrust, Netscape and Baltimore have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens like smart cards. IBM uses CDSA as its cryptographic framework that includes support for hardware devices. Because Windows 2000 requires hardware devices to also support Plug and Play and Power Management features, and Microsoft's implementation of PC/SC includes support for these ease-of-use features, there are no plans to add support for PKCS#11 in Windows 2000.

Certificates

Because a certificate is a binding between a name and a public key value, a digital certificate will contain additional information to support this binding. Interoperability between PKIs is directly affected by the contents of a certificate and how information in a certificate is encoded, processed, or ignored.

Subject and Issuer Names

Most people would not think that name information in a certificate would cause interoperability problems. However, names are very problematic and how they are defined in certificates directly impacts applications that use PKIs. For example, if a certificate does not contain the e-mail address name as part of the Subject or Subject Alternative name then some older e-mail applications will not accept the certificate for digitally signing or encrypting e-mail messages.

It is also very likely that the names in a certificate will not be English since we live in a global economy comprised of international languages. It is quite possible that the name in a certificate may, in fact, be a Unicode string in order to support the international character set. Interoperability issues arise when certificates are rejected because the underlying PKI or application does not support Unicode strings. In some cases, the application will actually crash when a certificate contains a Unicode string in the Subject, Issuer, or Subject Alternative name. Windows 2000 supports the different encoding formats specified by RFC 2459 as well as Unicode. Current Netscape, Entrust, and Baltimore products either do not support Unicode name encodings or do so in limited circumstances.

Authority Information Access (AIA)

The need to find CA certificates dynamically during chain building is a desirable feature and can be solved using certificate information contained in the Authority Information Access (AIA) extension specified by IETF RFC 2459. While Windows 2000 supports this extension and will use it if present in a certificate, Entrust, Netscape, Baltimore and most commercial CAs do not support the AIA extension. This means that discovery of parent certificates either requires a central repository for lookup and retrieval, or requires that all CA certificates be present on the client machine. Installing all CA certificates onto a client is not practical for PKIs that operate across corporate boundaries such as in an extranet or Internet scenario. Likewise, a central repository accessible to all applications across multiple companies is not feasible. The AIA extension provides location information in the form of URLs that can be accessed using different access methods such as LDAP, HTTP, FTP, and so forth. The AIA may also contain multiple URLs, which provide a level of fault tolerance if one of the sources is not available. Again, while Windows 2000 supports this extension most PKIs do not, making dynamic certificate chain building problematic.

Authority Key Identifier (AKI)

A flexible PKI that expects its certificates to be used in other PKIs will be able to populate the Authority Key Identifier (AKI) extension with not only a unique key identifier but will also be able to populate it with Issuer and Serial Number. The Windows 2000 PKI will attempt to construct certificate chains using AKI with issuer and serial number first, then fall back to key identifier by itself, and finally issuer and subject name.

CRL Distribution Point (CDP)

The CRL Distribution Point (CDP) is a very important extension because it tells a PKI where to go look for revocation information. A PKI client will periodically need to retrieve a new CRL since they have validity periods measured in days, weeks, or months. The Microsoft PKI will look in the CDP extension for a URL that points to a network location from where the CRL object can be retrieved. This URL may be accessible using LDAP, HTTP, FTP, and so forth. The Windows 2000 PKI does not accept an X.500 directory name in the CDP extension since the Windows 2000 does not support X.500 naming. The absence of the CDP extension in certificates will cause a certificate to be rejected if the application performs revocation checking and a valid CRL is not available on the local machine.

Basic Constraints

Basic Constraints is the X509 version 3 extension used to distinguish between end-entity certificates and CA certificates. There are still some PKI clients today that do not recognize Basic Constraints, which leads to situations where an end-entity may act as a CA. Windows 2000 honors Basic Constraints in accordance with IETF RFC 2459 and will reject CA certificates that do not contain this extension.

Subject Alternative Name

The Subject Alternative Name is used by some applications such as S/MIME or IP Security to specify additional name information about the Subject name specified in the certificate. The Windows 2000 CA will issue certificates with this extension populated for e-mail name, user principal name (UPN), and domain name system (DNS) name.

Extended Key Usage (EKU) and Key Usage

Extended Key Usage (EKU) is a certificate extension that can be used to specify additional key usages. EKU is not the same as a policy extension but instead it defines how a certificate may be used. For example a certificate may include EKUs for secure e-mail and client authentication. Applications that recognize these extensions would then not allow the certificate to be used for other purposes such as code signing. If there are no EKUs in the certificate then it is good for all purposes specified by the Key Usage extension.

The Windows 2000 PKI honors both extensions to determine how a certificate can be used. Since not all EKUs are specified in IETF RFC 2459, other extensions are usually ignored by most applications unless they are marked critical. Unrecognized critical extensions will cause the certificate to be rejected entirely. It is usually a bad idea to put critical extensions in certificates since it limits interoperability, unless the intention is to limit the use of the certificate to a specific application that understands the critical extension.

Supported Standards

Interoperability is always bi-directional between vendor products. The Microsoft Windows 2000 PKI is designed to be compliant with the major public key standards. Microsoft continues to support interoperability by testing with a variety of third-party products from Netscape, Baltimore, VeriSign, and Entrust among others.

PKIX

Internet drafts, including RFC 2459, from the IETF Public Key Infrastructure (PKIX) working group can be found at https://www.ietf.org/html.charters/pkix-charter.html

X.509

The ITU X.509 specification that describes the format of a certificate can be found at https://www.itu.int/.

TLS

Internet drafts from the IETF Transport Layer Security (TLS) working group can be found at https://www.ietf.org/html.charters/tls-charter.html.

S/MIME

Internet drafts from the IETF S/MIME Mail Security working group can be found at https://www.ietf.org/html.charters/smime-charter.html.

Kerberos

Internet drafts, including RFC 1510 and PKINIT, from the IETF Common Authentication Technology (CAT) working group can be found at https://www.ietf.org/.

PC/SC

The Personal Computer/Smart Card specifications can be found at https://www.smartcardsys.com/.

Additional References

Resources

The latest security information available from Microsoft can be obtained at https://www.microsoft.com/security/.

Information for IT professionals can be obtained through the Microsoft TechNet CD subscription and Microsoft TechNet Web at https://www.microsoft.com/technet.

Information for software developers can be obtained through the Microsoft Developer Network (MSDN™) at https://msdn.microsoft.com/.

Documents

U.S. Government

The National Institute of Standards and Technologies (NIST), in conjunction with the Department of Defense (DOD) and the National Security Agency (NSA), have published information on the U.S. government's Federal PKI efforts. Published documents can be found at https://csrc.nist.gov/pki/.

Canadian Government

The Canadian government has a similar PKI effort under the auspices of the Treasury Board of Canada Secretariat. Published information on Canada's PKI efforts can be found at https://www.cio-dpi.gc.ca/.

For More Information

For the latest information on the Windows 2000 operating system, check out Microsoft TechNet or visit our World Wide Web site at https://www.microsoft.com/windows.

1	CRL Distribution Point (CDP) is patented and licensed from Entrust.