Deploying the PKI841
Chapter 16
Designing a Public Key Infrastructure
Microsoft® Windows® Server2003 enables a variety of secure applications and business scenarios based on the use of digital certificates. Before you can use digital certificates, however, you need to design a public key infrastructure (PKI), which involves planning configuration options for one or more certification authorities, preparing certificates to meet the needs of your organization, and creating a PKI management plan.
In This Chapter
Overview of the PKI Design Process 730
Defining Certificate Requirements 735
Designing Your CA Infrastructure 746
Extending Your CA Infrastructure 776
Defining Certificate Configuration Options 788
Creating a Certificate Management Plan 810
Deploying the PKI 830
Additional Resources 842
Related Information
· For more information about Windows Server2003 public key features, see the Distributed Services Guide of the Microsoft® Windows® Server2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).
· For more information about using certificates in conjunction with Encrypting File System, see the Distributed Services Guide of the Windows Server2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).
· For more information about deploying smart cards, see “Planning a Smart Card Deployment” in this book.
Overview of the PKI Design Process
Organizations use a variety of technology solutions to enable essential business processes, such as online ordering, exchanges of contracts, and remote access. A public key infrastructure based on Microsoft Windows Server2003 Certificate Services provides a means by which organizations can secure these critical internal and external processes.
Deploying a PKI allows you to perform tasks such as:
· Digitally signing files such as documents and applications.
· Securing e-mail from unintended viewers.
· Enabling secure connections between computers, even if they are connected over the public Internet or through a wireless network.
· Enhancing user authentication through the use of smart cards.
If your organization does not currently have a public key infrastructure, begin the process of designing a new public key infrastructure by identifying the certificate requirements for your organization. If your organization already uses a public key infrastructure based on Microsoft®WindowsNT®version 4.0, Microsoft® Windows®2000, or third-party certificate services, you can improve your PKI capabilities by taking advantage of new and enhanced features in Microsoft® Windows® Server2003, Standard Edition; Windows® Server2003, Enterprise Edition; and Windows® Server2003, Datacenter Edition. When you have completed the PKI design process, you can deploy a public key infrastructure that provides solutions for all of your internal security requirements, as well as security requirements for business exchanges with external customers or business partners.
Note
For a list of the job aids that are available to assist you with the PKI design process, see “Additional Resources“ later in this chapter.
Process for Designing a PKI
Designing a PKI for your organization involves defining your certificate requirements, creating a design for your infrastructure, creating a certificate management plan, and deploying your PKI solution. Figure15.1 shows the steps that are involved in designing a public key infrastructure.
Figure15.1Designing a PKI
Note
The steps involved in designing a PKI are interdependent. For example, defining certificate server configurations, locations, and roles has a significant impact on how you address key certificate management issues. Your evolving certificate management standards in turn have significant implications for the certificate server roles, locations, and configurations that you develop.
Basic PKI Concepts
Public key infrastructure is the term used to describe the laws, policies, procedures, standards, and software that regulate or control the operation of certificates and public and private keys. More specifically, a PKI is a system of digital certificates, certification authorities, and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction.
A PKI consists of the following basic components:
Digital certificates
Electronic credentials, consisting of public keys, which are used to sign and encrypt data. Digital certificates provide the foundation of a PKI.
One or more certification authorities (CAs)
Trusted entities or services that issue digital certificates. When multiple CAs are used, they are typically arranged in a carefully prescribed order and perform specialized tasks, such as issuing certificates to subordinate CAs or issuing certificates to users.
Certificate policy and practice statements
The two documents that outline how the CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on.
Certificate repositories
A directory service or other location where certificates are stored and published. In a Windows Server2003 domain environment, the Active Directory® directory service is the most likely publication point for certificates issued by Windows Server2003–based CAs.
Certificate revocation lists (CRL)
Lists of certificates that have been revoked before reaching the scheduled expiration date.
Note
With Certificate Services in Windows Server2003, Microsoft introduces a new type of certificate revocation list called a delta CRL, which allows you to publish information about recently revoked certificates more frequently without using the bandwidth required for publishing full CRLs.
Certificate trust lists
These are signed lists, which are located on the client, of trusted CA certificates. Certificate trust means that a certificate is part of a certificate trust list (CTL) or that the CTL contains a trusted certificate from another CA that is part of the certificate’s certificate chain. Windows Server2003 domain administrators can use Group Policy objects (GPOs) to publish and maintain CTLs.
Key archival and recovery
A feature that makes it possible to archive and recover the private key portion of a public-private key pair, in the event that a user loses his or her private keys, or an administrator needs to assume the role of a user for data access or data recovery. Private key recovery does not recover any data or messages; it merely enables the recovery process.
Public key standards
Standards developed to describe the syntax for digital signing and encrypting of messages and to ensure that a user has an appropriate private key. To maximize interoperability with third-party applications that use public key technology, the Windows Server2003 PKI is based on the standards recommended by the Public-Key Infrastructure (X.509) (PKIX) working group of the Internet Engineering Task Force (IETF). Other standards that the IETF has recommended also have a significant impact on public key infrastructure interoperability, including standards for Transport Layer Security (TLS), Secure/Multipurpose Internet Mail Extensions (S/MIME), and Internet Protocol security (IPSec).
Windows Server2003 PKI
You can use PKI-based applications on workstations and servers running Microsoft® Windows®XP Professional, Windows Server2003, Windows®2000, or WindowsNT 4.0, as well as on workstations running Microsoft® Windows®95 and Microsoft® Windows®98. The ability to create and manage a PKI is available in Microsoft® Windows NT®4.0 Server, Microsoft® Windows®2000 Server, and Windows Server2003. However, Windows Server2003 provides more extensive support for a PKI.
In addition, a growing number of applications and system services that require the secure transfer of information also rely on the Windows Server2003 PKI. Applications that are enabled for certificate-based security include Microsoft® Outlook®, Internet Explorer®, Internet Information Services, Microsoft® Exchange Server, Microsoft® Commerce Server2000 and Commerce Server2002, Outlook Express, and Microsoft® SQL Server™. A number of third-party applications also take advantage of the Windows Server2003 PKI.
How a Public Key Infrastructure Works
A Windows Server2003 PKI makes it possible for an organization to do the following:
· Publish certificates. The PKI administrator makes certificate templates available to clients (users, services, applications, and computers) and enables additional CAs to issue certificates.
· Enroll clients. To participate in a PKI, users, services, or computers must request and receive certificates from an issuing CA or a Registration Authority (RA). Typically, enrollment is initiated when a requester provides unique information and a newly generated public key. The CA administrator or enrollment agent uses the information provided to authenticate the identity of the requester before issuing a certificate.
· Use certificates. Clients use their certificates, which are validated or invalidated in a timely manner as long as CAs and certificate revocation lists are available to verify or deny their authenticity. If they are validated, a PKI provides an easy way for users to use keys in conjunction with applications that perform public key cryptographic operations, making it possible to provide security for e-mail, e-commerce, and networks.
· Renew or revoke certificates. A well-designed PKI makes it easy for you to renew or revoke existing certificates, and to manage the trust level associated with certificates used by different clients or for different applications.
The status of a public key certificate is determined by means of the chain building process. Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. Figure15.2 shows a certification path in a two-level CA hierarchy.
Figure15.2Certification Path in a Two-Level CA Hierarchy
In this example, the issuing CA issued the User certificate, and the root CA issued the certificate of the issuing CA. This is considered a trusted chain, because it terminates with a root CA certificate that has been designed and implemented to meet the highest degree of trust.
The chain building process validates the certification path by checking each certificate in the certification path from the end certificate to the certificate of the root CA. If the CryptoAPI discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is either considered invalid or is given less weight than a fully validated certificate.
For more information about how PKIs function, see the Distributed Services Guide of the Windows Server2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).
Defining Certificate Requirements
You can use a Windows Server2003 public key infrastructure to provide a wide range of strong, scalable, cryptography-based solutions for network and information security. The value of the information that you want to protect, as well as the costs involved with implementing a strong security system, impact the level of security that you choose for your organization.
Figure15.3 shows the steps that are involved in determining your certificate requirements.
Figure15.3Defining Certificate Requirements
Determining Secure Application Requirements
Before you begin to design your public key infrastructure and configure certificate services, you need to define the security needs of your organization. For example, does your organization require electronic purchasing, secure e-mail, secure connections for roaming users, or digital signing of files? If so, you need to configure CAs to issue and manage certificates for each of these business solutions.
A Windows Server2003 PKI can support the following security applications:
· Digital signatures
· Secure e-mail
· Software code signing
· Internet authentication
· IP security
· Smart card logon
· Encrypting file system user and recovery certificates
· 802.1x authentication
Digital Signatures
A digital signature is a means for originators of a message, file, or other digitally encoded information to bind their identities to the data. This can be extremely useful for important documents such as legal opinions and contracts. The process of digitally signing information involves transforming the information, together with some secret information held by the sender, into a tag called a signature. Digital signatures are used in public key environments to help secure electronic commerce transactions by providing verification that the individual sending the message is who he or she claims to be, and by confirming that the message received is identical to the message sent.
You can use digital signatures even when data is distributed in plaintext, such as with e-mail. In this case, while the sensitivity of the message itself does not warrant encryption, it can be important as a means to ensure that the data is in its original form and has not been sent by an impostor.
One way that your organization can capitalize on the use of digital signatures is by using CAPICOM. CAPICOM is an ActiveX control that provides a COM interface to Microsoft CryptoAPI. It exposes a select set of CryptoAPI functions to enable application developers to incorporate digital signing and encryption functionality into their applications. Because CAPICOM uses COM, application developers can access this functionality in a number of programming environments, such as Microsoft® Visual Basic®, Microsoft® Visual Basic® Scripting Edition, Active Server Pages, Microsoft® JScript®, C++, and others. CAPICOM is packaged as an ActiveX control, allowing Web developers to use it in Web-based applications as well.
You can use CAPICOM for:
· Digitally signing data with a smart card or software key.
· Verifying digitally signed data.
· Displaying certificate information.
· Inspecting certificate properties such as subject name or expiration date.
· Adding and removing certificates from the certificate stores.
· Encrypting and decrypting data with a password.
· Encrypting and decrypting data by means of public keys and certificates.
Secure E-mail
Standard Internet mail is sent as plaintext over open networks with no security. In the increasingly interconnected network environments of today, intruders can monitor mail servers and network traffic to obtain proprietary or sensitive information. You also risk exposure of proprietary and confidential business information when you send mail over the Internet from within your organization.
Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using readily available tools to counterfeit the originating IP address and mail headers. When you use standard Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid. Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks (for example, by sending attachments that contain viruses).
For these reasons, many organizations have placed a high priority on implementing secure mail services that provide confidential communication, data integrity, and non-repudiation. A Windows Server2003 public key infrastructure allows you to enhance e-mail security by using certificates to prove the identity of the sender, the point of origin of the mail, and the authenticity of the message. It also makes it possible to encrypt mail. To provide message authentication, data integrity, and non-repudiation, secure mail clients can sign messages with the private key of the sender before sending the messages. The recipients then use the public key of the sender to verify the message by checking the digital signature.