An Introduction to the Windows 2000 Public-Key Infrastructure

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Abstract

Public-key cryptography is a key technology for e-commerce, intranets, extranets and other web-enabled applications. However, to garner the benefits of public-key cryptography, a supporting infrastructure is needed. The Microsoft® Windows® 2000 operating system includes a native public-key infrastructure (PKI) that is designed from the ground up to take full advantage of the Windows 2000 security architecture.

This paper describes the fundamentals of public-key security systems, including what benefits they offer and what components are required to implement them. It also describes how the Windows 2000 PKI components deliver the needed services while providing interoperability, security, flexibility, and ease of use.

Overview

Public-key cryptography offers significant security benefits when it's properly implemented. Like other enabling technologies, public-key cryptography requires an infrastructure to deliver its benefits. However, the public-key infrastructure, or PKI, isn't a physical object or software process; instead, it's a set of useful services provided by a collection of interconnected components These components work together to provide public-key-based security services to applications and users.

This white paper has two goals: to explain public-key technology and its uses, and to describe the features and benefits provided by the native PKI in the Microsoft® Windows® 2000 operating system. Understanding both of these topics will help you to decide where you can use PKI technology to improve your business processes and increase your ability to securely handle transactions with others.

In this paper, you'll learn what a public key infrastructure is, what desirable benefits it can offer your operations, and how the Windows 2000 PKI delivers interoperability, security, flexibility, and ease of use.

This paper focuses on the business benefits of the Windows 2000 PKI. Readers who would like a more technical description should consult: MS Windows 2000 Public Key Infrastructure

Introduction

The purpose of a public-key infrastructure (PKI) is to make it easy for businesses to use public-key cryptography. Public-key cryptography is crucial for e-commerce, internet, intranet and other applications that require distributed security—security in which the participants are not part of the same network and have no common security credentials. Public-key cryptography provides the best, most efficient way to do this.

Public-key cryptography provides three capabilities that are especially valuable to businesses. First, it provides privacy for data. Second, it allows robust identification, or authentication, of users and machines. Finally, it provides non-repudiation—the ability to prove that someone took a particular action. Some examples of how businesses can use these capabilities include:

Privacy

Encrypting e-mails that will be sent across the Internet, preventing them from being read en route.
Encrypting network traffic when a customer visits your web site, protecting their ordering information and credit card numbers.
Encrypting a NetMeeting® conferencing software session to prevent eavesdroppers from listening in.

Authentication

Verifying the identity of a visitor to a corporate intranet in order to allow them to read certain files
Proving to a customer that they are at your web site and not a malicious site that is masquerading as yours.
Providing your company's annual report to your customers in a way that assures them that it is bona fide.

Non-repudiation

Creating an enforceable, tamperproof record of a customer's purchase requests at your e-commerce web site.
Signing legally-binding electronic contracts.

What is Public-Key Cryptography?

When most people hear the words encrypt or cryptography, they immediately think of secret-key cryptography, wherein two parties share a single secret key that's used both to encrypt and decrypt data. Loss or compromise of the secret key makes the data it encrypts vulnerable. By contrast, public-key systems use two keys: a public key, designed to be shared, and a private key, which must be closely held. These keys are complementary: if you encrypt something with the public key, it can only be decrypted with the corresponding private key, and vice versa.

Public-key systems depend on the mathematical relationship between the public and private keys. It's not feasible to derive one from the other. There are two fundamental operations associated with public key cryptography: encryption and signing.

The goal of encryption is to obscure data in such a way that it can only be read by the intended party. In public-key cryptography, if Bob wants to send Alice some private data, he uses her public key to encrypt it, then sends it to her. Upon receiving the encrypted data, Alice uses her private key to decrypt it. The important concept here is that Alice can freely distribute her public key in order to allow anyone in the world to encrypt data that only she can decrypt. If Bob and Chuck both have copies of her public key, and Chuck intercepts an encrypted message from Bob to Alice, he will not be able to decrypt it; only Alice's private key can do that, and she is the only person who holds it.

Signing also uses encryption, but the goal in this case is to prove the origin of a piece of data. If Alice wants the world to know that she is the author of a message, she encrypts it using her private key and posts it publicly. This does not provide any privacy for the data, because her public key is available globally and anyone can decrypt the data using her public key. However, the fact that it can be decrypted using Alice's public key means that it must have been encrypted using Alice's private key, which only she holds—so it must have come from Alice.

These two operations can be used to provide three capabilities – privacy, authentication, and non-repudiation—that make distributed security possible, and thereby allow e-commerce, intranets, extranets, and other web-enabled business processes to be successfully deployed.

Privacy

Privacy is a necessity for businesses of all kinds, but it's of vital importance for ones that use the Internet. The Internet allows anyone in the world to communicate with anyone else, but it doesn't provide security. Even within your company's internal network, if someone can gain physical access to your network media, they can eavesdrop on any data that traverses it.

Public-key cryptography provides privacy via data encryption, whether the data is in the form of e-mail messages, credit card numbers sent over the Internet, or network traffic. Because public keys can be posted freely, complete strangers can establish private communications simply by retrieving each other's public keys and encrypting the data.

Authentication

Any transaction involves two parties, whether they're a client and a server or a customer and a vendor. For many transactions, it's desirable for one or both sides to be able to authenticate, or verify the identity of, the other. For instance, before a customer provides their credit card number to an e-commerce web site, they will want to know that they are not talking to an imposter. One way that a customer can do this is by making the web site prove that it holds the right private key. For example, a web browser might encrypt a piece of information using the site's public key and ask the web server to decrypt it, thereby demonstrating that the server has the right private key, and proving its identity.

Authentication can also take the form of assuring your customers that you produced a particular piece of data and that it has not been tampered with. Public-key cryptography enables you to do this by means of a digital signature, a concept which is an extension of the public-key signing operation discussed above. If Bob wants to digitally sign his company's annual report, he first generates a unique fingerprint of the report using an algorithm called a hash algorithm. Hash algorithms are specially designed to guarantee that even a single changed byte in the document will generate a completely different hash. Next, he encrypts the report and the hash using his private key. Alice (or anyone else) can verify the origin and authenticity of the signed report by first decrypting it using Bob's public key, then calculating her own version of the fingerprint and comparing it to the fingerprint she received. If the two match, it proves two things: that the report has not been tampered with, and it came from Bob.

Non-repudiation

Businesses require the ability to enter into binding agreements, whether in the physical world or on the Internet. Suppliers and buyers need the assurance that if they enter into an agreement, the other party will not be able to repudiate the agreement at some later point. Digital signatures on electronic purchase orders, contracts, and other agreements are legally binding in several countries and in many U.S. states, and legal acceptance is rapidly growing.

What is a Public-Key Infrastructure?

Now that you understand what public-key cryptography is and why it's valuable, we can define what a PKI is. A PKI is the set of operating system and application services that make it easy and convenient to use public-key cryptography. A PKI gives you the ability to:

Manage keys: a PKI makes it easy to issue new keys, review or revoke existing keys, and manage the trust level attached to keys from different issuers.
Publish keys: a PKI offers a well-defined way for clients to locate and retrieve public keys and information about whether a specific key is valid or not. Without the ability to retrieve keys and know that they are valid, your users can't make use of public key services.
Use keys: a PKI provides an easy-to-use way for users to use keys—not just by moving keys around where they're needed, but also by providing easy-to-use applications that perform public-key cryptographic operations, making it possible to provide security for e-mail, e-commerce, and networks.

Once these capabilities exist, application developers can use them to build more secure applications. However, those applications depend on having a secure, easy-to-use, flexible way to manage, publish, and use public keys—that's where the PKI comes in.

A capability, not a thing

A common misperception is that a PKI is a thing. In fact, it's a capability—the capability to easily publish, manage, and use public keys. Think of a PKI like a municipal water system. A water system is made up of purification plants, storage towers, pumps, water mains, and so on, as well as the pipes and faucets in your house. All of the disparate service-providing objects work together to provide a capability for users to obtain water on demand. In a similar way, a PKI consists of a group of discrete components that work together to allow you to use public keys, and public-key cryptography, seamlessly and transparently.

The best place to implement a PKI is in the operating system. Operating systems already provide a number of other infrastructures, like the printing infrastructure that moves documents to printers and the file service infrastructure that retrieves files from shared storage. In both cases, the operating system provides a capability to transparently and easily use a network service, just as a PKI does.

Digital certificates: packaging for public keys

So far, this paper has mentioned public keys when talking about the objects that a PKI uses. While public keys are required for PKI-based security, they're usually packaged as digital certificates. (It's important to stress that only public keys are packaged into certificates. The private key is never shared, so it doesn't require packaging—it's simply stored securely). The certificate contains the public key and a set of attributes, like the key holder's name. These attributes may be related to the holder's identity, what they're allowed to do, or under what conditions the certificate is valid. The binding between attributes and the public key is present because the certificate is digitally signed by the entity that issued it; the issuer's signature on the certificate vouches for its authenticity and correctness.

For a real-world analogy, look in your wallet. If you have a drivers' license, you have the equivalent of a digital certificate. Your license contains a unique key (your license number) and some attributes (an expiration date, your name, address, hair color, and so on). It's issued by a trusted agency and laminated to prevent it from being tampered with. Anyone who trusts the agency that issued your license and verifies that the lamination is intact can rely on its authenticity. At that point, though, the analogy breaks down—in the real world, only the government can issue a driver's license, so everyone knows that a license issued by Joe's Really Good DMV isn't valid. How do you make the same determination with a digital certificate?

The answer lies in the concept of a certificate hierarchy. In a hierarchy, as shown in Figure 1, each issuer, or certificate authority, signs (using its own private key) the certificates it issues. The public half of the CA's keypair is itself packaged in a certificate—one that was issued by a higher-level CA. This pattern can continue through as many levels as desired, with each CA certifying the authenticity of the certificates it has issued. Eventually, though, there must be a top-level CA, called a root certificate authority. Since there's nobody above the root CA in the hierarchy, there's nobody to vouch for the authenticity and origin of its certificate. Instead, the root CA signs its own certificate—it simply asserts that it is the root.

Figure 1: What a certificate hierarchy looks like

Clearly, it's not secure to accept a root CA's assertion of its own identity. To verify a root CA's certificate, a trusted copy of its public key is obtained via an out-of-band method-—that is, it's delivered by a third party instead of over the network—and the key is used to verify that the root certificate is bona fide. Microsoft provides the public keys for many popular root CAs in PK-enabled products like Internet Explorer, allowing users to verify those roots transparently. Root CAs can also provide copies of their public keys for downloading from public web sites. Once the root key has been delivered via an out-of-band means, the user can verify the root certificate, and hence the entire certificate chain. Even better, because each certificate's digital signature protects it from tampering, certificate chains can be freely passed over insecure media like the Internet.

What components make up a PKI?

If digital certificates are the water in the plumbing of PKI, what about the plumbing itself? It's important to understand the five pieces that make up a complete PKI; these components create, validate, transport, and use the digital certificates that the PKI depends on.

Certificate authorities

A CA can vary dramatically in scope. At the large end are commercial CAs like Thawte, Verisign, Belsign, GTE Cybertrust or others. These commercial CAs issue certificates to millions of users. At the smaller end are CAs operated by departments within a company; these CAs issue certificates to a small number of users. These smaller CAs may be intermediateCAs whose certificates are signed by higher-level CAs inside the organization; those CAs may in turn have certificates signed by other CAs, all the way up to the root level.

Each CA has the responsibility to decide what attributes it will include in a certificate and what mechanism it will use to verify those attributes before issuing the certificate. For internal CAs, your organization can set its own policy, but you should be aware that other organizations may have very different policies than yours.

CAs also issue certificate revocation lists, or CRLs. When a certificate is revoked (either because the owner's private key has compromised or because the holder is no longer associated with the issuer), the CA adds it to the CRL, then publishes the CRLs so clients can check it. This mechanism is analogous to the stolen credit card list that card issuers publish; every authorization request must first clear this list before it can be approved.

Certificate publication points

Certificate publication points make certificates and CRLs publicly available, inside or outside an organization. This allows widespread availability of the critical material needed to support the entire PKI. In particular, a good certificate publisher will allow clients to automatically fetch certificates, including all certificates between the root and the desired certificate. Publishers can use any kind of directory service, including X.500, the Lightweight Directory Access Protocol (LDAP), or operating system specific directories; they can also publish certificates and CRLs on Web pages or distribute them on smartcards, disks, or CD-ROM. However, the market trend is clearly toward LDAP, which offer superior interoperability and flexibility.

Key and certificate management tools

There are a number of administrative requirements that businesses expect to apply to their PKIs. For example, sites must keep track of which certificates were issued, when they were issued, and who holds them; old certificates may need to be archived so that encrypted e-mail messages can be read even after the certificate is no longer active. There also has to be some way to control and monitor how the CA and certificate publisher are issuing and publishing certificates and CRLs; that's why one component of a useful PKI must be management, administration, and auditing tools.

Public key-enabled applications

Once your PKI can issue, publish, and control certificates, the next step is to deploy applications that can use them. A well-written application that is tightly integrated with the rest of the PKI can make the use of public-key cryptography all but transparent to the user. The user should not need to know how cryptography works, where certificates are stored, or any of the other details—they should simply indicate what they want done, and leave it to the applications and the PKI to make it happen.

Applications can use digital certificates to deliver the benefits of public-key cryptography, and they can combine cryptographic functions like signing and encryption to make possible e-commerce, secure network access, or other desirable services. All Microsoft applications that use public-key cryptography are natively public-key enabled. For example, the Microsoft Outlook® messaging and collaboration client offers built-in signing and encryption support, combined with the ability to use certificate publishers and root certificates from a number of sources. Internet Explorer, Microsoft Money, and Internet Information Server provide the ability to set up encrypted web sessions. PKI-enabled applications can build on industry-standard protocols to speed development and allow easy interoperability with other organizations, too.

Hardware support

The increasing market demand for PKI implementations has spurred hardware vendors to develop cryptographic hardware, including smart cards, PC cards, and PCI cards that offer onboard cryptographic processing. These hardware devices offer a wide range of capabilities. On the low end, smartcards offer limited cryptographic processing combined with secure key storage; on the high end, multiprocessor crypto-accelerators allow high-volume web services to secure data without suffering from bottlenecks caused by software cryptographic modules. The best thing about PKI hardware devices is that they're optional—if your application requires additional performance or security, you can add hardware to provide it as necessary, but you can still build a completely functional PKI in software.

The Windows 2000 PKI—Introduction

Microsoft Windows 2000 includes a full-featured public key infrastructure that delivers the business benefits of public-key cryptography. In contrast to third-party PKIs that must be purchased separately and add to your cost of ownership through per-certificate license fees and increased management tasks, the Windows 2000 PKI is delivered as part of the operating system, requires no per-certificate fees, and is seamlessly integrated into normal network management tasks.

The Windows 2000 PKI is built atop four pillars:

interoperability, or the ability to exchange messages, certificates, and services with other standards-based PKI components
security, provided both by using robust security algorithms and procedures and by depending on mature, well-tested code and algorithms
flexibility, or the ability to configure a PKI that precisely matches your specific organizational and business needs with minimum hassle
ease of use for PKI administrators, the end users who obtain and use certificates, and the applications developers who create PKI-enabled applications.

The Windows 2000 PKI builds on Microsoft's long-established track record of shipping robust PKI components. The primary components of the Windows PKI are:

Certificate Services, a core operating system service that allows businesses to act as their own CAs and issue and manage digital certificates
Active Directory™ directory service, a core operating system service that provides a single place to find network resources; it serves as the publication service in the PKI.
PKI-enabled applications like Internet Explorer, Microsoft Money, Internet Information Server, Outlook, and Outlook Express, as well as myriad third-party applications that work with the Windows 2000 PKI.
The Exchange Key Management Service (KMS), a component of Microsoft Exchange that allows for the archiving and retrieval of keys used to encrypt e-mail. In a future version of Windows, the KMS will become subsumed into the Windows operating system as an enterprise-wide KMS

The Windows 2000 PKI—Interoperability

The point behind having a PKI is to be able to generate certificates easily and get them where they're needed. Within a single enterprise, it may be possible to use a vendor's proprietary solution, but the explosive growth of the Internet, intranets, and e-commerce means that cross-enterprise communications are likely to involve PKI components from multiple vendors. The existing security and communications standards for PKI components were developed by standards bodies and vendors with a strong vested interest in promoting good interoperability. These organizations include the World-Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), and the International Telecommunication Union (ITU). Microsoft works closely with these impartial bodies to ensure that its implementation of the standards are correct and fully interoperable.

The reason for these standards is simple: the only way to achieve true interoperability is through the wide distribution and use of open, vendor-neutral standards. Microsoft has embraced the key PKI security standards and has implemented them in its products. These standards are listed in Table 1, along with brief descriptions that explain why they're significant.

Table 1 PKI standards supported by Windows 2000

Standard	What it defines	Why it matters
X.509 version 3	Format and content of digital certificates	Without a standard for certificate formats, there's no way to exchange certificates between vendors
CRL version 2	Format and content of certificate revocation lists	Sites need to have a way to interchange revocation information
PKCS family	Format and behavior for public-key exchange and distribution	Allows different vendors' implementations to request and move certificates in a way that all understand.
PKIX	Format and behavior for public-key exchange and distribution	PKIX is an emerging PKI standard that many major vendors and enterprises are adopting in place of the PKCS standards.
SSL version 3	Encryption for web sessions.	SSL is the best-known and most widely used security protocol on the Internet, but it's subject to export controls.
SGC	Provides SSL-like security without export complications	SGC allows full 128-bit security and is exportable for certain uses
IPSec	Encryption for network sessions using the Internet Protocol (IP)	IPSec promises to offer transparent and automatic encryption of network connections.
PKINIT	Emerging standard for using public keys to log on to networks that use the Kerberos authentication protocol	Kerberos identifies users on the network; PKINIT allows Kerberos to use digital certificates on smart cards as credentials.
PC/SC	Standard for interfacing computers to smart cards.	Any vendor's smart cards that adhere to this standard can be used under Windows 2000 without the need for proprietary software

The Windows 2000 PKI—Security

A PKI is worthless if it doesn't offer robust security, because its entire purpose is to add security to your enterprise. An insecure PKI component can actually be worse than having no PKI at all, because it may lead you into a false sense of security. That's why it's reassuring to understand the security features built into Windows 2000, and to know that the Windows 2000 PKI, as a part of the operating system, inherits them.

Security through standards

The first, and most obvious, security feature in the Windows 2000 PKI is that its components rely on open industry security standards. In addition to the interoperability benefits mentioned earlier, using widely available standards increases security. The security standards listed in Table 1 were developed by computer security and cryptography experts, with significant input from the computer, banking and financial services, legal, and government sectors. That means that these standards reflect the real-world needs and concerns of industries that demand ironclad security.

The ultimate test of how secure an algorithm or protocol is how long it's been in successful public use. Microsoft has been careful to use mature algorithms and protocols that have passed this test of time, not those that were developed by single vendors without widespread public dissection and review. Windows 2000 includes support for all the major cryptographic algorithms, including RSA and DSS (public-key encryption), MD4, MD5, and SHA-1 (hash algorithms), and RC2 and RC4 (secret-key encryption).

Security through integration

Windows 2000 offers an open security architecture that allows third-party applications, including third-party PKIs, to use its robust security features. However, because the Windows 2000 PKI is a part of the operating system, it provides the best, most seamless integration with the Windows 2000 Active Directory service, native security protocols, and other security features.

Integration with Active Directory

Active Directory provides a single store for all network information and credentials. The Windows 2000 PKI uses this store for public key information; as a result, there are no new tools to learn, components to install, or applications to manage. This stands in sharp contrast to PKI component products that create their own separate stores for certificate and CRL data—these solutions force you to maintain separate databases for users, computers, and PKI data instead of keeping them in a single well-integrated store.

Certificates, CRLs, and policy information all are stored in Active Directory, meaning that they can be replicated, mirrored, and partitioned using Active Directory's native features. The Active Directory directory service also provides fine-grained access controls, so administrators can precisely specify who can see, change, and copy directory information. PKI components that integrate with Active Directory can use its policy mechanisms to control who may request certificates, who may fetch them from the directory, how long certificates remain valid, and so on.

Integration with security protocols

Windows 2000 provides native support for SSL, SGC, the IPSec protocol suite, and other critical protocols. As a result, Microsoft's PKI components don't have to reinvent the wheel. There's only one implementation of each protocol, meaning that the Windows 2000 PKI can take advantage of a single well-tested, thoroughly optimized protocol handler. In contrast, other PKI vendors may implement their own potentially untested and unoptimized versions of these protocols.

Integration with native Windows security

Using a secure system as the base for a PKI means that you can have confidence in the security of the underlying OS, not just the security of the PKI itself.

The Microsoft Windows NT® operating system was designed from the beginning to offer robust security. Every object in the system—including blocks of memory, disk files, processes, and physical devices like floppy drives and printers—can have access controls applied to it, and the operating system rigorously checks the identities of all users before granting them access to the system. In addition, both Windows NT and Windows 2000 provide complete auditing and logging.

The security of the Windows NT family isn't simply an assertion—it's been verified by third-party security experts. Windows NT 3.5 was evaluated by the US Government and meets the C2-level requirements in the "Orange Book" security criteria, and Windows NT 3.51 was evaluated at a roughly equivalent level (E3/F-C2) under the UK government's ITSEC process. Windows NT 4.0 has successfully been evaluated at the same E3/F-C2 level, and is nearing completion of a C2 evaluation as well. When Windows 2000 is released, Microsoft plans to submit it for evaluation under the Common Criteria, an emerging standard that will consolidate the US and UK evaluation processes.

Microsoft also has submitted cryptoalgorithm implementations to the National Institute of Standards and Technology (NIST) for evaluation against the Federal Information Processing Standard (FIPS) FIPS-140-1 standard. FIPS 140-1 is the benchmark against which all commercial implementations of the DES, DSS, and SHA-1 algorithms are judged.

These evaluations are important because they test against stringent, widely-accepted requirements for information protection and assurance and are conducted by independent security experts. Successfully completing these evaluations means that customers don't need to take Microsoft's word for it—they can see the results of third-party evaluations for themselves.

The Windows 2000 PKI—Flexibility

For a PKI to be useful, it has to conform to the way your enterprise chooses to do business. When talking about PKI components, flexibility means that you can configure how certificates are issued, distributed, and used in the software, and that the PKI itself supports more than one organization model for you to use.

Flexibility pays off in two ways. The first, and most obvious, is in lower total cost of ownership. A well-configured PKI that can be set up the way you need it doesn't force you to waste money on buying extra servers, add-on modules, or per-certificate licenses. The second way is in increased security—by deploying only those PKI components that you need, and configuring them the way you want, you can tailor the PKI's security services to your business needs. Because you can configure the product the way you want it, there's little risk of using a component to provide a service it's not designed to deliver securely.

Choose your CA model

The first, and longest-lasting, choice you face when implementing a PKI solution is what CA hierarchy model to use. Each model has its own technical and political advantages and constraints; understanding which model to use is a key part of planning your PKI deployment. Since the Windows 2000 PKI doesn't require any particular CA model, you're free to mix and match from the standard models as needed. For example, some organizations prefer the idea of outsourcing all of their certificate management and issuance, while others prefer to keep everything in house. Windows 2000 accommodates both of these extremes, and everything in between.

The standalone CA model

The standalone CA model (see Figure 2) is probably familiar to you if you've used SSL-protected web sites. In the standalone model, some third-party entity holds the root key and certificate for your organization, and it issues and revokes all certificates for your users. This third party might be a commercial CA like VeriSign, Thawte, Belsign, or GTE Cybertrust; it could also be a bank, a law firm, a trade association, or any other organization that you trust to issue certificates on your behalf.

Figure 2: The standalone CA model

This model allows trust both within and outside your organization, so you can exchange secure e-mail and e-commerce transactions with outsiders. Standalone CAs also free you from the complexities of issuing, revoking, and tracking certificates. However, it requires you to trust some outside entity with your certificate management, and many third-party CAs levy an individual charge for each issued certificate.

The enterprise CA model

In this model (see Figure 3), your enterprise acts as its own CA, issuing and revoking certificates subject to your business requirements. Because no outsourcing provider is involved, your organization maintains complete control over its PKI. In addition to that control, though, you can guarantee that no one outside the enterprise can obtain a certificate unless you issue it to them. This model works well for controlling access to internal resources, or for generating certificates whose attributes would be meaningless to an outside entity. For example, you could issue certificates to managers that would allow them to make electronic travel reservations through the company travel office.

Figure 3: The enterprise CA model

Enterprise CAs with subordinates

You can expand the flexibility of the enterprise CA model by adding subordinate CAs for individual departments, business units, or subdivisions of the organization. Most organizations already delegate some amount of administrative control to their subunits. For example, individual managers at most companies have some level of purchasing authority; higher-ranking managers can write bigger checks. Even though there's a centralized purchasing department that does much of the enterprise-wide buying, individual units still have the ability to perform day-to-day purchasing tasks.

Figure 4 shows how this model looks. Each subordinate CA issues certificates for its own users; the corporate root CA issues certificates to the subordinate CA. This split preserves overall control of the PKI at the organization level, while still allowing individual CA owners to handle managing certificates for their own users.

Figure 4: Combined enterprise & subordinate CAs

Combining standalone and subordinate CAs

Mixing the standalone and subordinate models provides maximum flexibility. Figure 5 shows one such combination. In this model, you combine a commercial root CA with subordinate CAs throughout the enterprise. This provides the best of both worlds. Having a commercial root CA means that you can exchange data with business partners and customers without having to invite them directly inside your own PKI, while maintaining your own set of subordinate CAs means that you retain control over certificate issuance and revocation inside your organization.

Figure 5: Combined standalone and subordinate CAs

Mixing and matching

There's no limit to how you can combine these models, or on how you configure your Windows 2000 PKI to accommodate your business policies and requirements. Figure 6 shows a case in which a user has been issued three certificates, one used for authenticating to the corporate human resources system, one used in conjunction with a corporate intranet, and one used to sign e-mails that may be sent to anyone in the world. Each certificate was issued by a different CA, using a CA model that's appropriate for it. This is analogous to physical credentials—in your daily life, you probably combine government-issued credentials with those issued by private employers and companies whose services you use.

Figure 6: Mixing certificates from three roots gives maximum flexibility

In the case of the certificate that allows access to the local human resources application, the issuer established their own local CA, in order to manage it locally and ensure that certificates could only be issued to employees. In the case of the certificate that allows access to the corporate intranet, the issuer wanted to maintain control over the certificates issued to employees, but yet still allow corporate partners to have certificates. In the case of the e-mail signing certificate, the key is to have a certificate that anyone can validate, so a commercial CA was selected.

Choose your validation criteria

The Windows 2000 PKI also allows you flexibility in your choice of validation criteria. These criteria determine what happens when a user tries to use a certificate; they typically includes a check to make sure the certificate is not revoked and has not expired, and they may also include a check on the certificates of the issuing CAs—all the way up to the root CA, if desired.

Of course, for the PKI to apply any kind of certificate checking criteria it has to have CRLs and certificates to check against. This has been a major stumbling block for PKI deployment in the past, since legacy PKI systems have not offered good ways to make certificate and CRL information available between sender and recipient. The Windows 2000 PKI stores certificate and CRL information in Active Directory (AD) so that AD and LDAP clients can retrieve it; in addition, clients can fetch CRL and certificate data from Web servers, and the sender (or his administrator) may choose to include the entire certificate and CRL chain as part of each outgoing messages. This allows you to let the directory do the work of serving validation information, while still retaining the option to deliver it to clients that can't retrieve it themselves.

One important note about the Windows 2000 PKI implementation of certificate validation is that searching, matching, and validation happen transparently. Neither the sender nor the recipient (whether it's a program or a human) needs to be aware of how the validation was done or what criteria were used, although any validation can be expanded to give full details on which certificates and CRLs were checked and what the results were.

Choose your trust model

If the choice of a CA model is the most important one you face when implementing a PKI, choosing a trust model comes in a very close second. When you trust a root, you're making an implicit statement that you trust them to be careful about who they issue certificates to. In this case, careful isn't quite the right word; what you're really saying is that you trust them to follow their prescribed policies and procedures to verify the identity of a certificate holder when they issue the certificate.

When you choose to trust a root certificate, you're also choosing to trust certificates signed by that root. Depending on the CA model you use, the practical impact of this choice could be large (as when you choose to trust a large, widely used commercial root CA) or small (like deciding to trust your own accounting department). Normally these decisions are made for the enterprise as a whole; however, the Windows 2000 PKI allows individual users (or their administrators) to make their own trust decisions. In addition, administrators may override or augment user trust decisions with group policies.

You also have to choose what you trust certificates to be used for. The X.509 v3 certificate standard allows you to specify whether certificates can be used for signing, encryption, or both. For example, you might want to give everyone signature certificates but restrict the use of encryption-capable certificates to certain departments or individuals. Microsoft has extended this feature to allow you to specify additional uses, including signing software components, logging on using a smart card, or recovering an encrypted file. When using the Windows 2000 PKI, the issuer has total control over what the certificate can be used for.

Choose what you delegate

The essence of good management is knowing when and what to delegate; this is true for PKI management too. In most enterprises, a central organization (or several groups) is responsible for maintaining access to information resources, using whatever tools are necessary to deploy information while still meeting corporate policies.

The Windows 2000 PKI gives you flexible tools to control what users can and cannot change on their own, including validation policies, trust decisions, and certificate usage. These tools are based on AD group policies and provide a flexible method for moving policies from the general to the specific. Group policies can be inherited, and each level in an organizational structure can have its own settings that govern which settings that level inherits and which ones are overridden. Policies govern:

Whether newly added users and computers will be automatically enrolled and issued certificates
What root certificates are considered to be trusted, and whether lower-level objects may modify this list or not
Whether settings in an individual group policy may be inherited or must be inherited by lower-level objects

Figure 7 shows one possible policy arrangement for a hypothetical company. The corporate IT department establishes a default trust list, specifies who may change it, and turns on AD inheritance so that the policy will be distributed to all subordinate objects. This distribution, and the tracking of who can change what, is all automatically handled by the AD. This group policy applies to every other object in the AD unless someone who appears on the delegate list for that object has changed the policy.

Figure 7: Policy inheritance controls policy use

The three subordinate departments each have their own set of group policies:

The group policy for the marketing group allows administrators to add to or remove root CAs from the local trust list, which starts off as a copy of the list inherited from the corporate root. Marketing administrators can't change other settings, though.
The group policy for the R&D department forces that department's users to trust only the root CAs specified by the network administrator; the users' local trust lists can't be modified.
The joint venture group has its own local root, and its local administrators make all the trust decisions. No information from the root-level policy is used, even though it's available through inheritance.

Handling advanced security needs

Some organizations have particularly stringent security needs. For example, the U.S. Department of Defense specifies three security levels for its CAs: high, medium, and low. Outside the military and government sectors, many companies in the financial services, legal, medical, and industrial fields need to implement stronger security on some components of their PKI.

The Windows 2000 PKI fully supports these kinds of security requirements. For example, the existing Department of Defense certificate policy says that certificates for low-assurance CAs must be reissued every 5 years, while medium- and high-assurance certificates must be reissued every 3 years. The solution is simply to define two separate certificate templates with different validity periods. As another example, administrators have full control over when and how CRLs are generated and distributed, meaning that organizations like credit-card issuers that have specific time constraints for issuing new CRLs can meet them automatically.

The Windows 2000 PKI—Ease of Use

All of the interoperability, security, and flexibility features discussed so far are worthless if they're too hard to use. Historically, interface complexity has hampered the large-scale deployment and adoption of PKI components, and the training and support cost for older, hard-to-use products has been prohibitive.

Microsoft has expended a great deal of effort on making the Windows 2000 PKI ease to use for three key groups: end users, administrators, and developers. The end result is that the Windows 2000 PKI is easy to use because the PKI components are:

included with the platform, so there's nothing extra to buy or install. This is particularly attractive when you want to mix in departmental or business unit CAs, since the CA software itself is part of the core OS.
largely automatic, so that PKI-related tasks happen as part of the normal function of the system
fully integrated with familiar tools, including the Microsoft Management Console (MMC), Internet Explorer, and the other management tools that users and administrators already know how to use

Ease of use for end users

It doesn't matter how wonderful your security system is if your users refuse to use it because it's too hard for them to use. The advantage of Windows 2000 PKI is that it can deliver advanced security services to everyone in your organization, not just power users. Requesting a certificate requires a single mouse click (see Figure 8), either through Internet Explorer or the Windows 2000 Certificate Manager. In either case, the Certificate Request Wizard is simple to use—users fill out a short series of wizard pages and the request is automatically forwarded to the responsible CA. Once their certificates are processed (usually in real time), the private key material can be delivered straight to the client, and the public portion is automatically stored in Active Directory for later use.

Figure 8: Requesting a certificate takes only one mouse click

When users need to manage their own certificates, they can do so with the Certificate Manager snap-in for the MMC or through the security preferences dialog in Internet Explorer. Through either of these avenues, they can request new certificates, view their own or other certificates and their validated chains, see what certificates are authorized to do, and so on.

This ease of use extends to applications that are written using Microsoft's PKI support libraries (see "Ease of use for developers" for details on what's in these.) Any third-party developer can easily include access to the full range of Windows 2000 PKI capacity, making their applications PKI-aware without requiring users to learn anything new. For example, an e-mail application can add a simple checkbox or toggle button that allows users to encrypt or sign mail, without requiring them to understand the underpinnings of the cryptography involved.

Ease of use for administrators

Installing a PKI is usually the easy part for administrators—once all the components are in place and working, the day-to-day tasks needed to keep everything running take precedence. By contrast, the few management tasks required to maintain the Windows 2000 PKI occur as part of the normal system housekeeping Windows NT administrators already know how to do.

In Windows 2000, the MMC is the administrator's standard workspace for all administrative tasks, including those related to PKI management. From the Certificate Services MMC snap-in, administrators can easily perform all the everyday tasks required for normal PKI maintenance:

They can revoke certificates when necessary.
They can view the properties (including validity interval, last update time, and certificate membership) for certificates or CRLs.
They can define templates for certificate attributes; newly created certificates inherit these attributes automatically.
With appropriate permissions, they can change group policy settings for users, groups, and computers.

These tasks are all integrated with the existing MMC, and they're performed using the same familiar tools and commands. For example, Figure 9 shows that to revoke a certificate, all an administrator has to do is right-click the certificate and choose the "Revoke Certificate…" command.

Figure 9: Revoking a certificate is a one-click operation

The Active Directory Users and Groups snap-in allows administrators to manage Active Directory itself. Along with the standard directory management tasks you'd expect to see, administrators can create group policies to apply network-wide trust decisions, automatically enroll users or machines by issuing them certificates from a particular issuer, or manage the location and availability of individual certificates or CRLs.

Ease of use for developers

Cryptographic programming is not for the faint of heart. Understanding the algorithms is easy, but implementing them correctly, with no security mistakes, is difficult. Microsoft's PKI components provide easy-to-use, well-documented ways to use cryptographic routines that are implemented as part of the OS. These routines have been extensively tested and validated (see "Integration with native Windows security"), so developers can take advantage of them with confidence that they're not introducing their own security holes. That's why developers have been so quick to enthusiastically embrace the cryptographic services included with Windows.

Developers who want to create PKI-aware applications find that it's much easier to do than they expected because of the Windows 2000 security services. These services save time and improves security by eliminating need for every developer to be an expert cryptographer. Windows 2000 provides three separate sets of security services:

CryptoAPI 1.0 provides pre-written public- and secret-key cryptographic services. Applications can request encryption and decryption services without needing to know the intricacies of the algorithms and protocols used.
CryptoAPI 2.0 provides certificate handling services for certificate-aware applications. It provides the ability for applications to request certificates, validate certificate chains, and get certificate-related information from the local or Active Directory certificate stores.
The Security Services Provider Interface (SSPI) allows developers to use Windows 2000 network security services. SSPI-aware applications can map certificates to Windows accounts, establish SSL sessions, open IPSEC tunnels across the network, and take advantage of the full breadth of Windows 2000's network security services.

Windows 2000 also offers built-in support for smartcards and cryptographic accelerators; that means that developers can take advantage of these services with zero additional overhead or effort on their part. Any device whose manufacturer releases a CryptoAPI provider module can be used with almost no additional programming.

Summary

Public key cryptography offers critical business advantages, including the ability to conduct e-commerce and normal business operations with increased privacy, security, and assurance. To deliver these benefits, a public-key infrastructure is necessary that makes it easy to manage, publish and use public keys. Windows 2000 offers a PKI that is completely integrated with the operating system and provides flexible, secure, interoperable services that are easy to use, easy to deploy, and easy to manage.

For More Information

For more detailed information on the Windows 2000 PKI, see Microsoft TechNet or https://msdn.microsoft.com/library/en-us/dnsecure/html/pki.asp
For the latest information on Windows 2000 security, see Microsoft TechNet or visit the Microsoft Security Advisor page at https://www.microsoft.com/security/.
For the latest information on Windows 2000, see Microsoft TechNet or visit our World Wide Web site at https://www.microsoft.com/windows2000/.