Cryptography and Microsoft Public Key Infrastructure

This article is a sample chapter (Chapter 6) from the Microsoft Press book Microsoft Windows 2000 Security Technical Reference. To order a copy of this book, go to https://www.microsoft.com/mspress/books/3873.aspx.

This chapter introduces cryptography and Public Key Infrastructure (PKI) and explains why and how to deploy them in your Windows 2000 environment. The first part of the chapter explains the security services offered by cryptography, the building blocks of cryptography, the importance of key relationships and exchange, and the high-level cryptographic services available to applications and operating systems. The second part of the chapter describes how you can use PKIs in Windows 2000 and how to configure the certificate services in Windows 2000. The third part of the chapter discusses how to go about designing your PKI, whether provided by Microsoft or by third parties.

On This Page

An Introduction to PKI
Cryptographic Background
Cryptographic Services
Microsoft PKI
Designing Your Public Key Infrastructure
Summary

An Introduction to PKI

A PKI allows client and server applications to gain trust in each other's authentication credentials in a highly scalable and efficient manner. Applications can then employ those credentials to perform strong authentication and make use of end-to-end confidentiality and integrity services.

To show where a PKI might prove useful, let's look at the case study of a company called Exploration Air that wants its customers to have access to an internal Web server. Exploration Air expects a number of users in each customer organization to securely log on to the Web server. The challenge lies in managing authentication credentials for all those external users. If Exploration Air uses passwords, their IT department is expected to somehow identify those users, as well as process password changes for them. This solution does not scale well, and for a large number of users it becomes unmanageable. Attackers can also guess passwords, and passwords might not offer strong enough authentication for high-value transactions.

With a PKI, Exploration Air can delegate the issuing of authentication credentials to certification authorities run by the customers themselves, or to a commercial certification authority. This way, the company needs to configure its Web server only to trust those authorities. Those credentials also offer strong authentication because they cannot be guessed.

Now let's say that Exploration Air wants to exchange secure e-mail with users of the same customers. A password infrastructure is actually incapable of offering end-to-end secure e-mail among multiple users, and no such implementations exist. Technically, the servers that hold the passwords would have to get involved for every recipient, for every e-mail sent. The servers would also have access to either the contents of the e-mail or the secret key material that protects the confidentiality or integrity of messages. In contrast, public key–enabled e-mail clients can directly exchange secure e-mail using the authentication credentials of their users.

Windows 2000 PKI Offerings

Windows 2000 offers a comprehensive mechanism for issuing certificates that allows organizations to take full advantage of the PKI technology. Microsoft's adherence to industry standards means Windows 2000 will interoperate with any third-party public key–enabled software.

Windows 2000 will work equally well with certificate services offered by other PKI vendors. Windows 2000 can also participate in Internet-based commercial PKIs, such as the one offered by VeriSign.

Windows 2000 offers the following PKI features:

• A number of public key–enabled applications and services: Internet Information Services, Internet Explorer, Microsoft Outlook and Microsoft Outlook Express, Encrypted File System (EFS), IPSec, and smart card logon.

• Active Directory, which you can use as a publication point for certificates and certificate revocation lists (CRLs).

• Microsoft Certificate Services, which enable an organization to issue its own certificates and implement its own PKI.

• Support for smart cards in Windows 2000, which you can use for key storage and cryptographic operations (in addition to logons).

• Commercial certification authority (CA) certificates preloaded in Windows 2000, which enable users and computers to participate in existing PKIs on the Internet.

• Public Key policies in the Group Policy, which allow administrators to control the external CAs that users and computers can trust.

These features are implemented on industry standards such as X.509, LDAP, SSL/TLS, S/MIME, IPSec, and the Public Key Extensions of Kerberos, enabling interoperability with third-party applications and PKIs.

Cryptographic Background

Cryptography provides the following security services to the operating system and applications. In this chapter, we use the term entity to refer to both users and servers.

Confidentiality

Confidentiality ensures that only authorized entities have access to information. This service is particularly useful when you must store sensitive data in vulnerable locations such as laptops, or transmit it across vulnerable networks, such as the Internet or an outsourced WAN. Cryptography then helps by turning big secrets (your data) into small secrets (the cryptographic keys). Keys are easier secrets to manage, especially since they can be exchanged in advance.

Entity Authentication

The entity authentication service proves one entity's identity to another, and it is commonly implemented by demonstrating the possession of a secret. Cryptography helps by keeping that secret private during the authentication process.

Data Integrity

The integrity or data authentication service assures that a chunk of data did indeed originate from an entity and that it remains unaltered. Cryptography helps by binding the data to its originator. In some contexts, integrity might be defined only as ensuring that data remain unaltered.

Nonrepudiation

Nonrepudiation enables users to digitally sign electronic documents and be legally bound by the signatures, as if those signatures were handwritten. Cryptography can provide evidence that a user signed a document, but a lot of conditions need to be met for a court to consider this legally binding. Some countries and some U.S. states legally recognize digital signatures. You can find more information on this issue at https://www.mbc.com/ecommerce.html and https://rechten.kub.nl/simone/ds-lawsu.htm.

PKI Basics

Entities can have one or more private-public key pairs and associated public key certificates. A certificate is a statement issued by a certification authority according to a policy that binds an entity's public key to its name for a period of time. (You'll learn more about policies later in the chapter.) Another entity that trusts this CA also trusts that the public key belongs to the named entity.

When entity A is presented with a certificate by entity B, entity A can tell from the certificate name that the certificate belongs to a legitimate user of the system. Entity B proves he or she is the legitimate holder of the certificate by proving his or her knowledge of the associated private key. Entity A can optionally check the certificate's current validity by looking it up on the CA's CRL.

Furthermore, entities A and B can now use end-to-end confidentiality and integrity services without the cooperation of any third entity. For example, users can exchange secure e-mail and securely access Web content on an intranet.

For certain applications, this security model presents some advantages when compared to a security model that forces all entities to share secret keys with central authorities. One advantage is that users and computers can authenticate thousands or millions of other entities in a scalable manner, without the immediate cooperation of a mediating server such as a Windows domain controller, a Kerberos Key Distribution Center (KDC), or a CA. For example, almost all Web browsers can authenticate a Web server bearing a certificate from VeriSign, a universally trusted commercial CA.

Another advantage to this model is that users and computers can efficiently use end-to-end security services between them, without the immediate cooperation of a mediating entity. For example, users can exchange confidential e-mail without sharing the contents or keys that protect the contents with mediating servers.

A third advantage is that private keys are typically 1024-bit-long strings and cannot be guessed the way that passwords can. Therefore, you can use certificates for strong authentication.

Finally, account databases need not store a secret for every user and computer. Active Directory actually stores hashed passwords for use by Kerberos and other authentication protocols.

Multiple CAs and Issuing Policies

An enterprise can have multiple issuing CAs to serve the different certificate needs of users and to implement different security policies.

Note that CAs also have a private-public key pair and the associated public key certificate. Multiple CAs are typically linked together in a hierarchy, with parent CAs issuing certificates to subordinate CAs. Trust in a CA implies trust in its subordinate CAs. Therefore, if you trust the root CA at the top of a hierarchy, you implicitly trust all CAs in it.

Users and computers are typically configured to trust root CAs. Therefore, they can efficiently authenticate entities bearing certificates from any subordinate CA. An organization's CA can even be certified by a universally trusted commercial CA, which could make the certificates it issues recognizable by other organizations.

The certification authority issuing policies we've mentioned so far describe a) how the CA identifies users and computer before issuing them a certificate; and b) what legal liabilities, if any, the CA accepts by issuing a certificate.

Policies, on the other hand, might be less important for certificates issued by an organization for internal use. A policy created for this situation could be equivalent to your policy for issuing user passwords. Policies are essential when you use certificates to communicate with other organizations—or when other organizations use them to communicate with you.

Policies are also essential when other organizations issue certificates to your organization and vice versa. Examples include having your own CA certified by a commercial CA, or issuing certificates to customers for use in an extranet application.

Cryptographic Services

This section introduces some building blocks in cryptography and the security services they offer. If you are familiar with cryptography, feel free to skip this section.

Symmetric Cryptographic Algorithms

Symmetric cryptography is the classic form of cryptography. People have relied on it for thousands of years to keep messages private.

Symmetric cryptography works by transforming (encrypting) the plaintext (the original data) to ciphertext (the protected data) in a way that makes it infeasible to reverse the process without the full knowledge of the transformation function. For a number of reasons the secret transformation is split into a constant part, the cryptographic algorithm, and a variable part, the cryptographickey. The algorithm can be widely deployed in software or devices that use cryptography, and in general it is not assumed to be secret. Therefore, all security lies in keeping the key secret.

By definition, the reverse process uses the same key—hence the name symmetric cryptography. The decryption transformation turns the ciphertext back into the plaintext. The transformation is split into a decryption algorithm and the same cryptographic key.

Symmetric keys are either random blocks of data or are derived from user passwords, and are usually 40 to 128 bits in length. Symmetric algorithms use symmetric keys and a block algorithm such as DES, DESX, RC2, or RC4 to encrypt and decrypt raw data.

Asymmetric Cryptographic Algorithms

Asymmetric, or public key, cryptography also turns plaintext into ciphertext using an algorithm and a key. The difference lies in the use of a different decryption key, hence the name asymmetric.

The decryption (private) key and the encryption (public) key are related to each other, but the former cannot feasibly be derived from the latter. Therefore, the encryption key need not be kept secret, and can even be made public. Instead, users of public keys need to trust that a given key does belong to a particular owner. This issue is addressed by the process of certification (described later in the chapter). Security lies in keeping the private key secret.

Asymmetric keys are randomly chosen from a set that has certain properties specific to the asymmetric algorithm, so that two users are unlikely to generate the same keys. Key sizes commonly range from 512 to 4096 bits. Asymmetric cryptographic algorithms, such as RSA, encrypt symmetric keys in key exchange protocols and in hybrid cryptographic systems.

Asymmetric Signing Algorithms

You can also reverse the one-way relationship between asymmetric keys to sign data with a private key and verify the signature with the public key. This is because the signature could only have been feasibly generated with its associated private key. Asymmetric cryptographic keys are used for digital signatures and Challenge-Response authentication. Some common asymmetric algorithms include RSA and Digital Signature Algorithm (DSA).

Asymmetric Key Exchange

Some public key algorithms, notably Diffie-Hellman, can directly generate a shared secret, given two private-public key pairs. This is in contrast to exchanging a previously generated secret by protecting it with an asymmetric cryptographic algorithm.

As with asymmetric keys, these keys are randomly chosen from a set that has certain properties specific to the asymmetric algorithm, so that two users are unlikely to generate the same keys. Key sizes commonly range from 512 to 4096 bits.

Hashing

A hash function is one-way transformation that efficiently turns arbitrary-length data into fixed-length data, and given some data or its hash value, it is computationally infeasible to find some other data that will hash into the same value. Some applications also require the hash function to be collision-resistant, so that it is hard to find any two inputs with the same hash value.

Therefore, if two documents hash into the same value, we can be certain that they are identical. So when we want to efficiently or privately compare two pieces of data, we can compare their hash values. For example, we can verify that a message was delivered intact by comparing its hash value before and after delivery. And we can securely compare two secrets by comparing their hash values.

Hash algorithms are commonly used for digital signatures, passphrases, integrity protection (for tasks such as software distribution), and Challenge-Response authentication. Hash algorithms such as MD5 and SHA-1 commonly use hash values from 128 to 160 bits long.

Cryptographic Services

Windows 2000 combines the cryptographic building blocks to provide cryptographic services to applications. When more than one entity is involved, you can assume that shared and public keys have been exchanged.

Hybrid Encryption

Applications frequently employ hybrid or bulk encryption when they are required to apply a confidentiality service to shared data. This protocol assumes that the receiver has a private-public key pair and that the sender has obtained the public key.

A typical example is that of the SSL/TLS protocol used in secure Web browsing: The browser software (the initiator) is preloaded with some CA public keys, and the Web server (the receiver) has an asymmetric key pair and a certificate issued to itself from one of those CAs.

The browser then can generate a random symmetric key, encrypt it with the public key, and send it to the server. This is now a shared secret key, and the operation is essentially a key exchange. Either party can now use the key to encrypt data with a symmetric encryption algorithm and send the data to the other party.

The symmetric encryption is used because asymmetric algorithms are many times slower than symmetric algorithms and therefore not typically used for bulk encryption of data.

SSL/TLS, S/MIME, secure e-mail in Microsoft Exchange, and EFS all use hybrid encryption to provide a confidentiality service.

Digital Signatures

Digital signatures offer a data authentication service, ensuring that a message did indeed originate from an entity, and that it is unaltered.

Digital signatures are also hybrid in nature, again for efficiency reasons: A hash function is first applied to the data to be signed, producing a hash value or message digest. Then an application applies the asymmetric signing algorithm to the digest, using the signer's private/signing key. The digital signature consists of this signed hash, and is appended to the message.

The verifier repeats the first step to obtain the hash of the message he or she received, and then applies the asymmetric signing algorithm to the digital signature, using the signer's public/verifying key, which yields the original hash, and compares the two.

Any changes to the received message will change its hash. Also, any intentional changes to the signed hash are computationally infeasible without access to the private/signing key.

Digital Signatures offer data authentication services to Authenticode, S/MIME, and secure e-mail in Microsoft Exchange.

Message Authentication Codes

Message Authentication Codes, or MACs, offer a data authentication service similar to digital signatures, but use a shared symmetric key. MACs are only meaningful to those who possess the signing/verifying key.

One category of MACs called HMACs uses keyed hashes. HMACs concatenate a symmetric key with the message before hashing. Therefore, only the key holders can compute the message digest.

Another method for calculating MACs involves symmetrically encrypting the message with a block cipher in cipher block chaining (CBC) mode. In that mode, each plaintext block is combined (XORed or binary added) with the previous ciphertext. The final ciphertext is the MAC. The most common implementation uses the DES algorithm in CBC mode.

MACs provide data authentication services to SSL/TLS and IPSec.

Challenge-Response Authentication

Challenge-Response authentication mechanisms offer an entity authentication service. They authenticate one entity to another by proving knowledge of a credential (shared secret or private-public key pair) while keeping that credential private.

The authenticator challenges the authenticated party with a challenge, or nonce. The authenticated party responds with a cryptographic function of both nonce and the credential. The authenticator can then verify the response using the shared secret or corresponding public key.

When the credential is a shared secret, the cryptographic function can be a symmetric encryption algorithm or a hash function (or a MAC). If the credential is a private-public key pair, an asymmetric signing algorithm is used.

Challenge-Response authentication protocols include NTLM, SSL/TLS client authentication, digest authentication in Microsoft Internet Explorer and Microsoft Internet Information Services (IIS), and Point-To-Point Tunneling Protocol (PPTP).

Certification and Key Exchange

To use any kind of cryptographic services with more than one entity, these entities first need to share a secret or each other's public keys to authenticate one another.

Note: Authentication is necessary to protect against active "man-in-the-middle" attacks, in which an attacker masquerading as one of the legitimate parties can insert messages into the communications channel. Without authentication, it is still possible to preserve confidentiality and integrity, assuming only passive (eavesdropping) attacks are possible.

If only one entity makes a public key available to the other, only that entity can be authenticated—not the other. This is sufficient in some scenarios, such as a Web server proving its identity to Web browsers.

Windows 2000 actually has a native "secret-key" infrastructure (based on the user and computer passwords stored in Active Directory) and can also run and make use of a PKI. These two infrastructures complement each other and solve different problems, as discussed in the Microsoft PKI section earlier in this chapter.

Secrets are shared in the following ways:

• Long-term secrets are typically established out-of-band (for example, outside the untrusted communication medium over which applications apply cryptographic services) between entities and central authorities. A typical example of this is the logon password that users share with Active Directory.

• Short-term secrets are intended to protect the contents of a session. They can be established through the process of key exchange if long-term secrets or public keys are already shared. (This process is described in the following section.)

Public keys are shared in the following manner:

• Users and computers obtain the public keys of certification authorities they trust in an out-of-band manner or over a secure channel. For example, in Windows 2000 public keys are either preloaded into the operating system or securely propagated in the Group Policy.

• Users can now obtain the public keys of other entities over untrusted channels, packaged in certificates issued by those certification authorities. The certificates allow them to trust that the public keys belong to the named entities.

Key Exchange

Key exchange, or key agreement, is a category of protocols that allows two entities that share a long-term secret or at least one public key to establish a short-term shared secret.

Key exchange protocols make use of the symmetric and asymmetric protocols described earlier in this chapter. Some Windows 2000 protocols that perform key exchange are Kerberos v5, SSL/TLS, and IPSec. For further information about these protocols, see Chapter 5, "Authentication."

Certification

Certification is the basis of a PKI. Certification binds a public key with the key holder's name and the intended key usage for a period of time. It is performed by a CA, and provides assurance (to entities who trust it) that the public key does indeed belong to the named entity. The resultant certified public key is called a digital or public key certificate, or simply a certificate. Certificates are sometimes published in a directory or distributed by their owners.

Users and computers who trust a CA and have its certificate can verify the certified public keys of other entities that have registered with it. Services (typically Web services such as IIS) can use certificates to identify users, map them into Windows accounts, and give them access to resources. The discretionary access control lists (DACLs) on the resources determine the users' authorization.

CAs can also set up trust relationships with each other. In a hierarchical CA model, such as the one in Windows 2000, the child (subordinate) authority would obtain its certificate from its parent CA. End users who trust a parent CA trust all its subordinates' CAs.

We'll discuss the hierarchical model further in the Microsoft PKI section later in this chapter. At this point it is worth mentioning that CAs at the top of hierarchies are called root, and only issue certificates to subordinate CAs, not to end users. Root CAs have by necessity self-signed certificates—in other words, they issue certificates to themselves by signing their public keys with their own private keys. By trusting a few root CAs, therefore, users and computers can efficiently verify the certificates of millions of other entities.

End users can also generate self-signed certificates when the users generate a key pair and no CA is available to enroll with. This typically happens when EFS is used in the absence of a Windows 2000 Enterprise CA. Such certificates are of value only to their owners, since other users cannot trust or verify them.

Technically, certification is performed by digitally signing the end user's public key together with identifying information (for example, name and e-mail address), using the CA's private/signing key. The CA's public key is widely distributed; users who choose to trust the public key can use it to verify its digital signatures on certificates.

Thus CAs are trusted for a number of things, including properly identifying key holders before issuing them a certificate, revoking this certificate when it is no longer valid, and keeping their own private/signing keys confidential. You need to document these issues in the CA's certificate practice statement (CPS), especially if you use its certificates to communicate with other organizations.

The next section describes why and how certificates are revoked.

Certificate Revocation

Revocation is the act of canceling a certificate, effectively recalling the issuer's signature on the combination of public key and user name.

The following situations can result in certificate revocation:

• The user changes his or her name.

• The user's private key is compromised; the user will enroll separately for a new certificate under a new key pair.

• The issuer's signing key is compromised. If other parties can now issue certificates on behalf of the issuer, all issued certificates are now invalid.

• The user leaves the organization or the part of the organization for which the CA is responsible.

• The computer owner of the certificate (computer owners can have keys, too) is replaced, compromised, or decommissioned.

Technically, revocation is performed by publishing the certificate's serial number in a CRL signed by the issuing CA.

A CA's certificate is revoked if its private key is compromised, because now other parties can issue certificates on its behalf. Therefore, all its certificates, including ones issued to subordinate CAs and their issued certificates, are also considered revoked.

Certificate Renewal

Renewal is the act of issuing a new certificate using the same name, a new serial number, and perhaps (but not necessarily) a new key pair. Renewal does not affect the validity of the old certificate.

You should renew user and computer certificates just before they are about to expire. For CA certificates, renewal should happen earlier, because for a certificate to be valid at any given time, the certificates of the issuing CA and its parents must also be valid. It would be unfortunate if a CA certificate expiration caused any issued certificates to expire. Therefore, Microsoft CAs implement time nesting, meaning that they will not issue certificates that will expire later than their own certificates. This time-nesting policy can cause problems toward the end of a CA's certificate lifetime. For example, if a CA issued certificates one month before its certificate expired, those issued certificates would need to have an expiration period of less than one month.

Therefore, you should renew a CA certificate when its remaining lifetime approaches the longest validity period of certificates it issued. For example, a CA that issues certificates valid for two years should have a lifetime of four years, and renew its certificate every eighteen months.

After renewal, an entity uses the new certificate and key pair, if any. The old set is archived to decrypt and verify old and even new documents.

Microsoft PKI

The Windows 2000 PKI consists of a number of components:

• The public key–enabled applications and services. These are IIS, IPSec, smart card logon, EFS, Internet Explorer, Outlook, and Outlook Express. These components interact with each other, and they make use of the cryptographic security services. Some of them also perform key management. They are all standards-based and can interoperate with non-Microsoft entities. They obtain the keys or certificates they need from their own user's or host's store, Active Directory, and Exchange.

• The user and host certificate stores. These store the entity's own certificate, if any, and a pointer to the cryptographic service provider that holds the private key. They also store the certificates of trusted CAs and other entities. These certificate stores are made available to the PK-enabled applications.

• The Certificates MMC Snap-In for certificate management. This snap-in allows users to browse the certificate stores, export private certificates and private keys, and perform certificate enrollment with Microsoft enterprise CAs.

• The Public Key policies. These policies specify which CA certificates populate the user and host stores and how these certificates are trusted. They also define automatic certificate enrollment and renewal behavior for hosts. PK policies are defined in the Group Policy objects.

• The Certificate Services. These services allow you to implement your own PKI using the enterprise and standalone Microsoft CAs. Enterprise CAs issue certificates to domain users and hosts and publish them in Active Directory; standalone CAs are generic CAs that can issue any type of certificate to anyone, including non-Windows entities.

• Active Directory. Active Directory is a certificate publication point for Microsoft CAs.

Behind the scenes you will also find the cryptographic service providers (CSPs), which are accessible through the Microsoft CryptoAPI. CSPs offer key generation and other crypto services to the PK-enabled client software and the Microsoft CAs. CSPs also provide an interface to smart cards.

The next section will concentrate on the Windows 2000 Certificate Services, key management for users and hosts, and Public Key policies. First we will explain the purpose of a PKI in Windows.

Why Use a PKI?

Both Windows NT and Windows 2000 have a secret key infrastructure of sorts. All domain users and workstations have a shared secret key (password) relationship with the domain controllers (DCs). Those passwords are typically used with Kerberos and NTLM to authenticate users to services and DCs, as well as to authenticate hosts to DCs. The passwords can also derive cryptographic keys that offer link confidentiality (with PPTP, for example) and integrity (for example, SMB signing).

The secret key infrastructure is well-suited to offer authentication services to the Windows 2000 domains found within a corporation. However, this model encounters trust and scalability problems as soon as you need other security services or your network needs to communicate with external users.

As we explained in the beginning of this chapter, the PKI enables entities across organizational boundaries to trust each other's credentials in an efficient manner. The PKI also enables end-to-end security services to be used between entities, and offers strong entity authentication. A PKI complements the Windows NT and Windows 2000 secret key infrastructure and allows you to exploit more security services across a more distributed environment.

Note that even if a Windows environment does not implement a PKI, the Windows 95, Windows 98, Windows NT, and Windows 2000 clients already participate in some Internet-wide, commercial PKIs. Those clients come preloaded with a number of commercial CA certificates, allowing them to authenticate other participating entities. This is how Internet Explorer and other Web browsers can establish secure SSL/TLS connections with Internet Web servers or verify signed code (for example, ActiveX components and other software) downloaded from the Internet and your intranet. Users can also verify signed e-mail sent to them, and if they enroll with a commercial CA and obtain their own certificates, they can also send and receive signed and encrypted e-mail. Windows 2000 enables the management of this trust in external CAs through the Group Policy.

Certificate Services

Certificate Services allows you to implement your own PKI. This section describes their components and installation.

Microsoft Certificate Services

Microsoft Certificate Services is the certification authority service. Its job is to accept certificate requests, issue certificates, and publish the CRL.

There are two kinds of Microsoft CAs: enterprise and standalone. An enterprise CA is meant to issue certificates to domain users and computers according to some ACLs. Windows 2000 services, such as EFS and interactive logons with smart cards, can use these certificates, and they can be published to Active Directory. A standalone CA is meant to issue certificates to entities outside your Windows 2000 domains, such as customers and users of other organizations.

Some of the differences between the two CAs are evident in the way their policy and exit modules work. You can actually replace those modules with your own in a standalone CA. For example, you might want to define a policy that automatically issues certificates according to certain rules.

Since standalone CAs can issue certificates to any kind of entity—even non-Windows 2000 entities—they are more suited to be your root CAs. They are capable of operating offline, as they don't need to automatically authenticate the requestors like the enterprise ones do. You'll find more information on this topic later in the chapter.

Certificate Templates

Templates are profiles that define the contents of certificates issued by Microsoft enterprise CAs. Those contents include user information such as name and e-mail address obtained from Active Directory, expiration time, and intended certificate usage.

Each template is defined by its intended usage. For example, the user template called "User" allows its holder to use EFS, to encrypt e-mail, to sign e-mail, and to authenticate himself or herself to Web servers. The computer template called "WebServer" allows its holder to authenticate itself to Web browsers. Table 6-1 provides a list of templates.

Table 6-1 Certificate templates.

Certificate template name	Certificate purposes	Issued to users or computers
Administrator	Code signing, certificate trust list (CTL) signing, EFS, secure e-mail, client authentication	Users
Authenticated session	Client authentication	Users
Basic EFS	EFS	Users
Computer	Client authentication, server authentication	Computer
Code Signing	Code signing	Users
Domain Controller	Client authentication, server authentication	Computers
EFS Recovery Agent	File recovery	Users
Enrollment Agent	Certificate request agent	Users
Enrollment Agent (Offline request)	Certificate request agent	Users
IPSec (Offline request)	Internet Protocol security	Computers
IPSec	Internet Protocol security	Computers
Router (Offline request)	Client authentication	Computers/routers
Smart Card Logon	Client authentication	Users
Smart Card User	Client authentication, secure e-mail	Users
Subordinate certification authority	All	Computers
Trust List Signing	CTL signing	Users
User	EFS, secure e-mail, client authentication	Users
User Signature Only	Secure e-mail, client authentication	Users
Web Server	Server authentication	Computers

Each domain forest has a single set of certificate templates stored in Active Directory. You can examine them with the Active Directory Sites And Services Snap-In. To do so, start the Active Directory Sites And Services Snap-In, choose Show Service Node from the view menu, expand the Services node, expand the Public Key Services node, and then select the Certificate Templates, as shown in Figure 6-1.

Each template has an attached ACL that specifies which users and computers can enroll for it or access it otherwise. For example, Figure 6-2 shows that all authenticated (domain forest) users can enroll for certificates of the User template. You cannot edit templates through the user interface.

Figure 6-1: Certificate Templates in Active Directory.

Figure 6-2: Access control on Certificate Templates.

You can configure each enterprise CA to issue only certificates of certain templates. For example, you might want to designate a CA to issue only Administrator certificates.

Standalone CAs also have certificate types, but they are not called templates, they cannot be examined through the user interface, and no ACL is attached to them.

Policy Module

The CA calls the policy module to decide whether a certificate should be issued, denied, or marked as pending for the CA administrator to review.

On an enterprise CA, the module provided with Windows 2000 will accept certificate requests from users with read and enroll access to the CA. The defining characteristic of an enterprise CA is that it authenticates the requesting entities using their domain accounts. By default, all authenticated (domain forest) users have such access, as indicated in Figure 6-3.

Figure 6-3: Access control on an Enterprise Certification Authority.

The module will then verify that the template against which the request was made is actually available for issuing by this CA, and then check that the user has enroll access to the template.

On a standalone CA, the policy module will accept requests from users with similar access to the CA, which by default is everyone, authenticated or not. It will then mark the requests as pending by default, or you can also configure it to issue them automatically. Templates are not defined for standalone CAs.

On both types of CA, the module will also add two X.509v3 extensions to the certificate with the following:

• CRL distribution point (CDP) records. These point to where the CA publishes its CRL.

• Authority information access (AIA) records. These point to where the CA's certificate is published.

Those pointers are in the form of a URL, and can point to Active Directory (LDAP), to the CA's Web interface (http) or to the CA's shared folder (file), if one is specified during installation. When forming those URLs, use the replaceable parameter syntax shown in Table 6-2.

Table 6-2 CA replaceable parameters.

Variable	Value
%1	DNS name of the certification authority server
%2	NetBIOS name of the certification authority server
%3	Name of the certification authority
%4	Renewal extension of the certification authority
%5	Location of the domain root in Active Directory
%6	Location of the configuration container in Active Directory
%7	The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end

Exit Module

The CA calls the exit module after it issues a certificate. The module's job is to publish the certificate in the location specified in the certificate request, typically Active Directory for enterprise CAs and the file system for standalone CAs. The module is also responsible for publishing the CRL.

Certification Authority Snap-In

The Certification Authority Snap-In—shown in Figure 6-4—allows you to view and manage certificates and requests, configure the CA, and manually publish the CA CRL.

Figure 6-4: The Certification Authority Snap-In.

This snap-in allows you to do the following:

• View the revoked certificates and manually publish the CRL.

• View and revoke issued certificates.

• View, issue, and deny any pending requests. Such requests are only possible on standalone CAs.

• View failed requests. Requests can be failed by the policy module if the requestor is not authorized to enroll in the CA's ACL or by the CA administrator who reviews the pending requests.

• For enterprise CAs only: view, add, and remove Policy Settings (the certificate templates) the CA is allowed to issue. You can specify which entities can be issued which certificate templates in Active Directory.

By right-clicking on the CA's name and choosing Properties from the context menu, and clicking on the General tab you can access the Properties sheet shown in Figure 6-5.

Figure 6-5: The Certification Authority Properties sheet: General.

With this sheet, you can do the following:

• View the CA's general properties. Those include the CA's certificate, as well as the CSP used for cryptographic operations, and the hash algorithm used for signing certificates.

• Configure and change the policy module. Options include the CDP and AIA extensions to be included in the published certificates, and whether requests are automatically accepted or made pending (standalone CAs only).

• Configure and change the exit module. You can view and modify the CRL publication points, as well as specify where the CA is allowed to publish certificates; this is specified in the request itself.

• View the data storage locations. These include the CA's configuration data, which are stored in Active Directory or a shared folder. You can also view the folders in which the Certificate database and the Request log are stored.

• Set Access Control on the CA. This allows you to specify who can manage it, enroll with it, and read its configuration information.

By right-clicking on the CA's name and choosing All Tasks from the context menu, you can perform the following tasks:

• Start and stop the CA. This is equivalent to starting and stopping the Certificate Services service from the Services Snap-In.

• Back up and restore the CA. You can choose to backup the CA's key pair as well as the issued certificate log and the pending request queue. You can also incrementally back up the latter two. Microsoft recommends that you use Windows 2000 Backup to back up the whole server. If you choose to use the CA Snap-In for backup, you should also use the IIS Snap-In to back up the IIS metabase. (The IIS metabase is required for the Certificate Services Web interface.)

• Renew the CA certificate. You can opt to generate a new key pair, too.

Installation

Before you set up a CA, you can create an issuer policy statement to be included or simply referenced in the CA's certificate. This will be visible with the Issuer Statement button whenever you view a certificate. The policy statement is defined in the CAPolicy.inf file that should be placed in the %systemroot% directory before you install the Certificate Services.

A user with local administrative privileges can install enterprise and standalone CAs from Control Panel. To do so, open the Add/Remove Programs tool, click Add/Remove Windows Components, select Certificate Services, click Next, and follow the onscreen prompts.

The wizard will prompt you for the CA type (enterprise or standalone; root or subordinate). See the "Designing Your Public Key Infrastructure" section later in this chapter to decide what kinds of CAs you need.

You can install enterprise CAs only on servers on Windows 2000 domains and only if you are a user with write access to Active Directory. You can find who has such access using the Active Directory Sites And Services Snap-In by inspecting the ACL in the Public Key Services node in the Services node. By default that is the forest root Domain Administrators. On a member server, though, this group is not by default a member of the local Administrators group, and you need to add it to perform any software installation.

Note: In the first release of Windows 2000, only users of this user's domain will be given enroll access to certificate templates. You might want to grant such access to the server's domain users, or even to authenticated users. The Knowledge Base article 239452 documents this issue.

If you select the Advanced Options, you will be prompted for the following:

• A CSP that the CA will use for its cryptographic operations. The default is the Microsoft CSP, which you should not change unless you have a specific need to use another one.

• A hash algorithm to use in signing certificates (defaults to SHA-1).

• An existing key pair to use when restoring an existing CA.

• A key length for the size of the private and public keys, which for the Microsoft CSP defaults to 512 bits. Microsoft recommends a key length of at least 2048 bits. Of course, this option is not available if you chose to use existing keys.

Next you will be prompted for the CA's naming information, which appears on its certificates. The name fields are as follows:

• CA Name. This is the name by which your organization will identify the CA. This corresponds to the Common Name field of the X.509 certificate and the Active Directory object. You can use any characters in this name, but a sanitized version is used for operations that can't handle special characters (filenames and Active Directory objects, for example). The certutil command-line utility can display the sanitized name for a CA.

• Organization. The legal name of your organization.

• Organizational Unit. The division to which the CA belongs. This is not associated with the Active Directory Organizational Units (OUs).

• Locality. Your city.

• State or Province

• Country. A two-character country code, as defined in the X.500 standard. For example, the United States is US, Canada is CA, and the United Kingdom is GB.

If you are installing a root CA, you will be asked for its validity period. A typical value is 2 to 10 years. For a subordinate CA, this value is determined by its parent.

Next you will be asked for the location of the certificate database and its log. For a standalone CA you will have to specify a shared folder where the CA will publish information about itself, such as its certificate and CRL. For an enterprise CA or a standalone CA whose installer has write access to Active Directory, this information is published in the directory and therefore specifying a folder is optional.

If you are installing a subordinate CA, you will also be asked for a parent CA. You can automatically request a certificate by pointing to the computer that runs the parent CA, or you can generate a request into a file and submit it manually (for example, into the parent CA's Web interface). If you do that—or if the CA sets the automatic request to pending by the CA—you will have to import the certificate into the CA later to enable it.

Command-Line Utilities

The Certificate Services come with three command-line utilities that extend the capabilities provided by the user interface. They are meant to be run by developers and knowledgeable certification authority administrators.

CertSrv

To start the CA as a standalone application and display its actions on the console for diagnostic purposes, type the command certutil –z at a command prompt. You cannot run it while the CA is run as a normal service, so you have to stop that first.

You can start and stop the CA service either from the Certification Authority Snap-In, from the Services node in the Services And Applications node of the Computer Management Snap-In, or by typing net start certsvc and net stop certsvc at a command prompt.

CertReq

You use this utility to request certificates from CAs.

CertUtil

Use CertUtil to perform the following tasks:

• Display Certificate Services configuration information or a file containing a request, a certificate, a PKCS #7, or certificate revocation list.

• Get the certification authority configuration string.

• Retrieve the CA signing certificate.

• Revoke certificates.

• Publish or retrieve a certificate revocation list.

• Determine whether a certificate is valid or whether the encoding length is incompatible with old enrollment controls.

• Verify one or all levels of a certification path.

• Resubmit or deny pending requests.

• Set attributes or an integer or string value extension for a pending request.

• Verify a private-public key set.

• Decode files based on hexadecimal or base 64.

• Encode files to base 64.

• Shut down the server.

• Display the database schema.

• Convert a Certificate Server 1.0 database to a Certificate Services 2.0 database.

• Back up and restore the CA keys and database.

• Display certificates in a certificate store.

• Display error message text for a specified error code.

• Import issued certificates that are missing from the database.

• Set and display certification authority registry settings.

• Create or remove Certificate Services Web virtual roots and file shares.

Certificate Lifecycles

This section describes how entities (users and hosts) manage, store, and use certificates. We'll discuss both the Microsoft Certificate Services and third-party PKIs.

An entity's private-public key pair can be seen as another credential, in addition to the Windows password shared between it and the domain controller. Since an entity's private key is not shared with anyone else, it has different generation and storage requirements than a Windows password. Also, the public key has certification (authentication) and publication requirements. Entities can and sometimes do have more than one key pair and associated certificate.

User Keys

Users can browse, export, or enroll for certificates by using Internet Explorer (by going to Tools, then Internet Options, and then selecting Content) or by using the Certificates Snap-In.

Generation and Certification

Key generation and certification happen together, and are normally initiated by a user requesting a certificate from a CA. The user generates the keys (except for Smart Card Enrollment) using one of the Cryptographic Service Providers available to his or her system.

The following list describes several ways to invoke a certificate request (which will trigger the key generation).

• At the Certificates Snap-In, expand the Personal node and right-click on Certificates. Select All Tasks and then select Request New Certificate, as shown in Figure 6-6. Only enterprise CAs in the domain tree are visible through this method.

• Point Internet Explorer at a CA's Web interface. That can be any CA: enterprise, standalone, or a non-Microsoft CA.

• The administrator at a smart card enrollment station who generates keys and certificates in smart cards on behalf of users can invoke certificate requests. The administrator does this using an enterprise CA's Web interface and Internet Explorer. The administrator needs to have an Enrollment Agent certificate.

• If a user attempts to use EFS without an EFS certificate, the action automatically triggers a certificate request. If no enterprise CA is available in the domain tree, the certificate will be self-signed (signed by the user's private key).

Figure 6-6: Requesting a certificate with the Certificates Snap-In.

In the first three cases, the user can choose a certificate template or type and—if using the snap-in—a friendly name for the certificate. By selecting Advanced Options, the user can also choose a CSP for key generation, enable strong protection for the private key, and with the snap-in, choose an enterprise CA. Using Web enrollment, the user can also choose the private key length and whether the key can be exported from its store once generated.

The Microsoft CAs also accept previously generated certificate requests in the PKCS #10 standard format used by Web servers and other applications.

Storage

The private key is managed by a CSP and stored in the user's profile or on a smart card. In the former case, the key's file permissions protect it. With strong protection enabled, you can encrypt the key with a password that must be entered every time an application needs the key. A private key stored on a smart card is protected by a PIN and by the physical properties of the smart card.

The public key is packaged into the certificate and also stored in the user's profile. Enterprise CAs will publish some types of certificates in Active Directory by default. Note that if you use roaming profiles, a user's certificate and private key is available on all domain Windows 2000 Professional workstations.

You can also import and export key pairs. You can mark private keys as exportable at generation or when you import them. Certificate export supports the DER X.509, CER X.509, and PKCS #7 standard formats. PKCS #12 is used when the private key is exported together with the certificate.

Publication

An enterprise CA automatically publishes some types of certificates on Active Directory. A standalone CA will not normally publish the certificate if requested using the methods described earlier. Third-party CA software might or might not publish certificates.

Note: Standalone CAs can publish a certificate in a location specified in the request, but the request methods in Windows 2000 do not specify a location.

Usage

You can use user certificates issued by the Microsoft standalone CAs and third-party CAs to access secure Web servers with SSL/TLS client authentication and for secure e-mail. You can also use certificates issued by Microsoft enterprise CAs with EFS and for smart card interactive logon using Kerberos.

A password might be required if you need to use a private key that has strong protection enabled.

Revocation

The issuing CA can revoke user and computer certificates for a number of reasons discussed earlier in the chapter. Some non-Microsoft CAs will allow users to revoke their own certificates.

Renewal

Users can renew their certificates before or after they expire. They can choose to keep existing key pairs or generate a new one.

Host Keys

Users with local administrative privileges can manage host key pairs using the Certificates Snap-In. This section only highlights the differences with the user key lifecycle.

Generation and Certification

You can invoke the certificate request at the snap-in or at the Web interface of a CA, where you will have to select the "local machine store" option.

You can set hosts to automatically enroll and renew their keys. We'll describe this procedure in the next section.

Storage

The machine's key store stores the private key. Note that private keys are not typically protected, since services that use them run unattended, with no user intervention.

Publication

Host keys are published in the same manner as user keys.

Usage

IIS uses host keys to authenticate itself to Web browsers. Windows 2000 optionally uses host keys with IPSec to authenticate the host to others.

Revocation

Host keys are revoked in the same manner as user keys.

Renewal

You can perform renewal manually—as with user keys—or automatically, if specified in the public key policies.

Public Key Policies

The public key security policies are set in Group Policy Objects and the Local Policy Object. You'll find them in the Group Policy snap-in, in the Security Settings node of the Windows Settings node under Computer Configuration. Note that these are computer policies; therefore, you can only define which computers—but not which users—will receive them within a site, domain, or OU. See Chapter 8, "Group Policy," for a full discussion.

Automatic Certificate Request Settings Policy

This policy defines whether computers should automatically enroll for certificates and which enterprise CAs they should contact. Computers can only request computer-related certificate types, such as those of IPSec or Web (SSL).

Trusted Root CAs and Enterprise Trust Policies

These policies define the following:

• Which root CAs users can trust when verifying certificates.

• Whether users are allowed to trust additional CAs of their own choosing.

• The key usage for the certificates issued by each of those CAs (the purposes for which those certificates are valid).

Microsoft CAs within your domain forest are automatically added to those policies. To distribute the certificates of non-Microsoft CAs within your organization, use the Trusted Root CAs policy.

To distribute the certificate of CAs that belongs to other organizations or to commercial CAs, use the Enterprise Trust policy. This policy contains certificate trust lists (CTLs), which are digitally signed lists of certificates and allowed key usages. To construct one, you need a Trust List Signing certificate from an enterprise CA.

Encrypted Data Recovery Agents Policy

This is not really a PK policy —it's a policy about EFS, a client of PKI technology. It defines whether there is an EFS recovery policy within the scope of the Policy object. If a recovery policy is defined, it is populated with the certificates of the recovery agents. A defined but unpopulated policy means EFS is not available. See Chapter 9, "Security Configuration and Monitoring," for a full description of this policy.

Active Directory

In the previous sections we explained how Active Directory supports different components of the Microsoft Certificate Services, as well as PKI in Windows 2000 in general. In summary, Active Directory has the following properties:

• It is used as a publication point for issued certificates, CA certificates, and CRLs.

• It stores the Certificate Templates used by the enterprise CAs.

• It defines which Group Policies are in force across domains, part of which are the public key policies.

• You can employ it to map certificates to users. This mapping is primarily used when users authenticate themselves to IIS using a certificate.

Designing Your Public Key Infrastructure

You can implement your PKI by using the Microsoft Certificate Services and Active Directory or other compatible products. The issues discussed in this section are largely independent of the PKI products you choose to use.

Identify Your Certificate Requirements

Your certificate requirements are driven by the Public Key–enabled applications you use or plan to use. Identifying those requirements will let you decide which users and computers need what type of certificates. For each set of users you should identify the following criteria:

• the types of certificates they need

• private key size

• cryptoalgorithms allowed

• key lifetime

• private key storage (on smart cards, for example)

• private key exportability

Then you can identify how many and what kind of CAs you need. Your options include:

• Microsoft enterprise CAs, which can automatically issue a certificate to a user or computer with a Windows 2000 domain account.

• Microsoft standalone CAs, which typically require an administrator to manually issue certificates.

• Third-party CA software.

• Commercial CA services on the Internet, such as those provided by VeriSign and Thawte. These have the advantage of preloaded certificates in most client software, and can be a common point of trust among organizations. The downside to these services is that the private key that directly or indirectly signs your certificates is not under your direct control—a private key compromise at the commercial CA also compromises all of your certificates.

CAs issue certificates for users and computers. If you have any number of CAs, it is likely that you will want to organize them into a hierarchy. This organizing is done by introducing root and intermediate CAs (also chosen from the preceding list), whose job is to certify the intermediate and issuing CAs, respectively. For an explanation of why and how to achieve this, see the information on trust strategies later in this section.

Secure E-mail

A secure e-mail service offers confidentiality and data authentication services by implementing encryption and digital signatures mechanisms. All users of secure e-mail need to have a key pair with an enabled certificate. The industry standard for secure e-mail is S/MIME. You can obtain S/MIME certificates from either Microsoft or commercial CAs.

One issue to consider is whether you intend to exchange secure e-mail with other organizations. If so, you will need to establish a key relationship with them. In other words, both organizations need to obtain a certified copy of each other's CA public key that issues e-mail certificates, or the key of one of its parent CAs. One solution is to have those CAs be subordinate to (have their public keys signed by) a commercial CA that most organizations trust.

Secure e-mail certificates are available from commercial CAs, Microsoft standalone CAs, and Microsoft enterprise CAs under the Administrator, Smart Card User, User, and User Signature Only templates.

If you use Exchange as your server, and don't intend to exchange secure e-mail with other organizations, you can also issue certificates with its Key Management Server (KMS). The KMS will be integrated into the Certificate Services and Active Directory in the next releases.

Secure Web Servers with SSL/TLS

This is the most widely deployed implementation of public key technology, in which the server uses a certificate to authenticate itself to browsers. Both external and internal Web servers can obtain their certificates from a commercial CA, whose certificate is already preloaded into browsers. Internal Web servers could also obtain certificates from your own CAs that are trusted by intranet browsers.

Server authentication certificates are available from commercial CAs, standalone CAs, and under the Computer, Domain Controller, and Web Server templates.

Secure Web Servers with SSL/TLS Client Authentication

Web applications that have a strong requirement for authentication can be configured to authenticate users (through Web browsers), using the users' certificates. Again, you can issue your own certificates or outsource them to a commercial CA.

Client authentication certificates are available from commercial CAs, standalone CAs, and under the Administrator, Authenticated Session, User, and User Signature Only templates.

Code Signing with Authenticode

Code signing is a data-authentication mechanism that allows entities to verify that software and documents have indeed been released by their authors, and that they haven't been tampered with. Microsoft's implementation of this technology is Authenticode.

Authors digitally sign their codes or documents using a key pair, and users verify this signature using the corresponding certificate.

Code-signing certificates are available from commercial CAs, standalone CAs, and under the Administrator and Code Signing templates.

Smart Card Authentication to Windows 2000 Hosts

You can use smart cards to provide strong authentication for interactive logons. You can obtain appropriate certificates only from Microsoft enterprise CAs using the Smart Card Logon and Smart Card User templates.

IPSec Without Kerberos

IPSec provides a confidentiality, integrity, and authentication service to TCP/IP. Windows 2000 computers use Kerberos with their computer account passwords for authentication within their domains.

Non-Windows 2000 computers and devices (routers, for example) cannot have computer accounts with the domain controllers and therefore cannot use Kerberos for IPSec authentication. In a similar manner, Windows 2000 computers that need to establish IPSec connections with other machines cannot have computer accounts with the domain controllers and therefore cannot use Kerberos for IPSec authentication. Instead, they can use a private-public key pair for authentication.

IPSec certificates are available from commercial CAs, standalone CAs, and under the IPSec template.

EFS

EFS provides a confidentiality service to NTFS. It employs user key pairs to encrypt and decrypt files and recovery agent key pairs for file recovery purposes. An agent key (for the Administrator) is created at installation, and then user keys are automatically generated the first time they encrypt a file with EFS.

EFS and EFS recovery certificates are available only from enterprise CAs under the Basic EFS and EFS Recovery Agent templates, respectively.

In an environment with no Microsoft enterprise CAs, all EFS certificates are self-signed.

Custom PK–Enabled Applications

You can write custom applications that make use of X.509 certificates. This feature permits developers to utilize the strong authentication provided by certificates in their own applications.

Define Certificate-Issuing Practices

If you decide to run your own CAs, you will need to draw a CPS specifying its policies and operational procedures.

Let's assume that an entity is presented with another entity's certificate, which proceeds to verify it. The CPS tells the verifier how trustworthy the certificate is—in other words, how likely it is to belong to its named owner, and how likely is it that the owner is still authorized to use it. This is particularly important if your certificate users communicate with other organizations that need to trust that those certificates are genuine and valid.

The CPS should indicate points such as the following:

• How users are authenticated before being issued a certificate

• Physical and computer security of the CA server

• CA private key length, certificate lifetime and certificate renewal intervals

• Policies for revoking certificates

• CRL publication points and intervals

Of course, you should address the same issues in internal documentation.

Define Your CA Trust Strategies

You will need to decide which CAs your users and computers can trust. If you run your own CAs, you should consider arranging them in a hierarchy.

CA Hierarchies

In theory, you could only have issuing CAs, and have all your users and machines (and your communicating partners, if any) trust them. The issue here is that every time a CA renews or revokes its certificate or a new CA is introduced, you will have to modify those trust relationships.

One common solution is to have a hierarchy of CAs, with root CAs certifying intermediate CAs and the intermediate CAs certifying the issuing CAs. That way your users and partner will only have to establish trust in a small number of root CAs, and changes in the subordinate ones will not affect them. Note that to establish a common point of trust with other organizations, you can pick a commercial CA to root part of your hierarchy.

Root CAs need only issue intermediate CA certificates infrequently and periodically publish their CRLs. Therefore, you can operate them offline for added security. Typically you should use a standalone CA and not an enterprise CA for this purpose, since enterprise CAs can only certify other Microsoft CAs, and you can't operate them offline due to their integration with Active Directory.

Figure 6-7 on the following page shows an example of a trust hierarchy.

Figure 6-7: Example of a CA trust hierarchy.

Trust in CAs

Domain users and computers need to obtain the certificates of your root CAs, possibly the certificates of other organizations' CAs (not necessarily root ones), and perhaps the certificates of commercial CAs (because you want to trust them as they let your Web browsers visit secure Web sites). All these CAs can form part of your hierarchy.

Every Windows 2000 computer has a single store for CA certificates to be trusted by the machine and its users. Note that this comes preloaded with the certificates of a number of commercial CAs. It is also automatically populated with the Microsoft enterprise CAs you might have.

You add to this store through the Group Policy, using the Trusted Root CAs and Enterprise Trust containers under Computer Configuration, Windows Settings, Security Settings, Public Key Policies. The former container is used for your own non-enterprise CAs you unconditionally trust; the latter is for the foreign CAs.

In the Enterprise Trust container you can optionally restrict certificate usage—for example, if you want to restrict users to only accepting certificates for e-mail use—even if the CA can issue any kind of certificate. You can also use it with non-root CAs if you want to restrict your trust to only a part of a foreign hierarchy.

Define the CA Server Security Requirements

If you implement your own PKI, a large part of your organizational security depends on the security of your CAs and their keys. And if you implement a hierarchy, the CAs at the top are more valuable than the ones at the bottom.

You can take the following measures to secure your CAs:

• Use hardware CSPs (smart cards, for example) for the root keys.

• Operate root CAs—or even intermediate ones—offline.

• Physically protect the CAs.

Define Certificate Lifetimes

Normally certificate lifetimes are nested. In other words, an issued certificate (of a users or a CA) expires before the certificate of the CA that issued it. Otherwise, after the CA's expiration, the issued certificate becomes invalid, even if it hasn't expired itself. Microsoft CAs enforce this nesting in their certificate issuing, but other CA products don't necessarily do that.

Key lifetimes are set as a matter of policy, and Windows 2000 cannot (currently) enforce their expiration.

Certificate lifecycles typically look like this:

1. The CA certificate is issued.

2. The user certificate is issued.

3. The user certificate might be revoked.

4. The user certificate is renewed or expires. (They all expire some time).

5. The CA certificate is renewed or expires. (They all expire some time.)

When choosing the lifetimes for those keys and certificates, you should consider these points:

• The length of user and CA private keys. Longer keys are harder to mathematically attack and therefore support longer lifetimes.

• Private key storage. A more secure key supports longer lifetimes. Hardware storage provides more security than disk storage.

• The security of the CA server. More security means longer lifetime for its keys.

• The security of the computer environment in which you store the keys of the issued certificates.

• The amount of administrative effort you are willing to devote to certificate renewal. Shorter lifetimes mean that renewals will happen more often, which might require some administrative effort.

• Certificate lifetime nesting.

At the end of the day, you must strike a balance between the risks you are willing to accept (key theft or mathematical attack) against the administrative effort you are willing to make. You must also draw a procedure regarding key pair renewal that users should follow when they renew their certificates.

Table 6-3 offers some examples of certificate renewal administration.

Table 6-3 Certificate renewal.

Purpose of certificate	Certificate lifetime	Renewal schedule
Root certification authority (4096-bit key)	20 years	Renew every 9.5 years to ensure that you can certify issuing certification authorities for the full 10 years. Renew with a new key pair at least every 20 years to limit the key lifetime.
Intermediate certification authority (3072-bit key)	10 years	Renew every 4.5 years to ensure that you can certify issuing certification authorities for the full 5 years. Renew with a new key pair at least every 10 years to limit the key lifetime.
Issuing certification authority (2048-bit key)	5 years	Renew every 2.5 years to ensure that you can renew 2-year certificates for their full lifetimes. Renew with a new key pair at least every 5 years to limit the key lifetime.
Normal users (512-bit keys)	1 year	Renew with a new key pair every year to limit the key lifetime.
Administrators (1024-bit keys)	2 years	Renew with a new key pair every 2 years to limit the key lifetime.
Computers (1024-bit keys)	2 years	Renew with a new key pair every 2 years to limit the key lifetime.

Define the Enrollment and Renewal Processes

You should define the procedures for enrollment and certificate renewal. As mentioned in the section on user keys earlier in this chapter, the following methods are available to interact with the Microsoft CAs:

• Using the Certificate Request Wizard. The Certificate Request Wizard, a part of the Certificates Snap-In, is only available to Windows 2000 entities accessing Microsoft enterprise CAs.

• Using a browser with the CA Web interface. This method is available to all kinds of entities.

• Using automatic certificate enrollment. This method is available to Windows 2000 computers only, as defined in the Group Policy.

• Using smart card enrollment. This method is only available to Windows 2000 entities accessing Microsoft enterprise CAs.

• Using the Microsoft Enrollment Control. This method is available for custom applications.

Web browsers also typically access non-Microsoft CAs.

Define the Revocation Policy

You should draw a revocation policy to define the circumstances under which certificates should be revoked. We discussed some reasons in the section on revocation earlier in this chapter. Note that revocation of a CA certificate implicitly means the revocation of all its subordinate CA certificates and issued user certificates. Those subordinate certificates will fail to validate when the verifying entities obtain a CRL showing the parent CA certificate as revoked.

Part of your policy should also define where and how frequently the CRLs are published. You should also specify—even within your system and application policies—how frequently the CRL should be downloaded by the verifying entities that accept the certificates as proof of identity.

Define the Maintenance and Disaster-Recovery Processes

You should draw procedures specifying how to back up, recover, and revoke your CAs.

If the CA fails, you can attempt to recover by fixing the computer problem affecting the server. If that is not feasible, you can replace the server and recover the CA keys and issued certificates from the backups. Microsoft CAs offer backup and recovery of that information.

If the CA is compromised, you should revoke its certificate as described in the previous section. This is quite a serious event, potentially affecting a large part of your infrastructure. Following the revocation you should proceed to inform your users, remove the certificate from the Group Policy (if the certificate is replicated through the Group Policy), replace the CA with a new one, and renew all the subordinate and issued certificates.

Document the Design

After you make all those decisions and draw the policies, be sure to document them!

We suggest that your Organizational Security Policy should reference a particular type of PKI. This high-level policy should reference a detailed PKI policy, which in turn should include a base certificate practice statement. You could establish the CPS of individual CAs on this base CPS.

Summary

This chapter introduced cryptography and the security services cryptography offers, as well as the public key functionality in Windows 2000 and the Windows 2000 Certificate Services. This public key functionality enables secure e-mail, secure Web browsing, strong authentication with smart cards, secure data storage, secure networking, secure software distribution, and efficient and scalable management of the necessary cryptographic keys. You can use the Windows 2000 Certificate Services together with Active Directory to implement your own PKI.