PKI Technologies

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

PKI Technologies

Organizations need enhanced security for data and strong credentials for identity management. You can use certificates to secure data and manage identification credentials from users and computers both within and outside your organization.

A public key infrastructure (PKI) is the combination of software, encryption technologies, processes, and services that enable an organization to secure its communications and business transactions. The ability of a PKI to secure communications and business transactions is based on the exchange of digital certificates between authenticated users and trusted resources.

You can design a PKI solution to meet the following security and technical requirements of your organization:

• Confidentiality. You use a PKI to encrypt data that is stored or transmitted.

• Integrity. You use a PKI to digitally sign data. A digital signature helps you identify whether another user or process modified the data.

• Authenticity. A PKI provides several authenticity mechanisms. Authentication data passes through hash algorithms, such as Shivest Hash Algorithm 1 (SHA1), to produce a message digest. The message digest is then digitally signed by using the sender’s private key to prove that the message digest was produced by the sender.

• Nonrepudiation. When data is digitally signed, the digital signature provides proof of the integrity of the signed data and proof of the origin of the data. A third party can verify the integrity and origin of the data at any time. This verification cannot be refuted by the owner of the certificate that digitally signed the data.

PKI Technologies Architecture

The architecture of a PKI involves implementing various interdependent technologies and processes to make it possible to issue, validate, renew, and revoke certificates. These technologies include:

• One of more servers running Certificate Services and that provide certificate enrollment, revocation and other certificate management services.

• Active Directory directory service or another directory service that provides account management, policy distribution, and certificate publication services.

• Domain controllers that can authenticate end users and computers when they request certificates.

• Domain client computers and users, who request, receive, and use certificates for specific purposes. Although certificates can also be used by services and by non-domain clients, in most Windows PKI environments, domain users and computers are the primary recipients and users of certificates. In some cases, the domain client can be a subordinate CA that requests and receives a certificate authorizing it to issue certificates of its own.

The following figure illustrates the architecture of PKI technologies.

PKI Technologies Architecture

PKI Technologies Components

The key technology components of a PKI and their relation to the PKI architecture diagram are described in the following table.

Components of a PKI

PKI Technologies Scenarios

A PKI consists of one or more CAs that play specific roles. One or more CAs of each type can be combined in a CA hierarchy.

Roles in a CA Hierarchy

Each CA in a CA hierarchy is assigned a role, which is determined by the CA’s location in the CA hierarchy. Common roles in a CA hierarchy include a root CA, a policy CA, and an issuing CA.

Root CAs

A root CA is the highest CA in a CA hierarchy and is the trust point for all certificates that are issued by the CAs in the CA hierarchy. If a user, computer, or service trusts a root CA, they implicitly trust all certificates that are issued by all other CAs in the CA hierarchy.

A root CA is different from all other CAs in that it issues its own certificate. This means that the Issuer and Subject fields of the certificate contain the same distinguished name. A root CA only issues certificates to other CAs that are directly subordinate to it.

Policy CAs

A policy CA is typically located on the second-tier of a CA hierarchy, directly beneath the root CA. In this scenario, the root CA is often referred to as a parent CA, because the root CA issued a Subordinate Certification Authority certificate to the policy CA. In fact, any CA that issues a certificate to another CA is referred to as a parent CA. The CA that receives the certificate from a parent CA is known as a subordinate CA.

The role of a policy CA is to describe the policies and procedures that an organization implements to secure its PKI, the processes that validate the identity of certificate holders, and the processes that enforce the procedures that manage certificates. A policy CA issues certificates only to other CAs. The CAs that receive these certificates must uphold and enforce the policies that the policy CA defined.

It is not mandatory to use policy CAs unless different divisions, sectors, or locations of your organization require different issuance policies and procedures. However, if your organization requires different issuance policies and procedures, you must add policy CAs to the hierarchy to define each unique policy. For example, an organization can implement one policy CA for all certificates that it issues internally to employees and another policy CA for all certificates that it issues to non-employees.

Issuing CAs

An issuing CA is typically located on the lowest tier of a CA hierarchy. An issuing CA issues certificates to other computers, users, network devices, services, or other issuing CAs. An issuing CA is always online.

The parent CA for an issuing CA can be a root CA, a policy CA or another issuing CA. The issuing CA must enforce the policies and procedures that are described in the policy CA above the issuing CA in the CA hierarchy.

Types of CA Hierarchies

You can use one of two CA models: a root hierarchy or a cross-certification trust. Windows Server 2003 networks recognize and support both models.

Root Hierarchies

In a root CA hierarchy, all of the CAs in the organization’s CA hierarchy are chained to a common root CA. The following figure illustrates a root CA hierarchy.

Root CA Hierarchy

A root CA hierarchy:

• Enhances security and scalability. It protects the upper layers of the CA hierarchy from network attacks by removing the upper layers of the CA hierarchy from the network.

• Provides flexible administration to the CA hierarchy. You can use role separation to delegate CA management to separate administration groups in an organization.

• Supports commercial CAs.All commercial CAs — such as VeriSign, GTE, Thawte, and RSA — implement trusted root CA hierarchies.

• Supports most applications.Applications such as Microsoft Internet Explorer and Netscape Communicator support certificates that root CA hierarchies issue, as do IIS and Apache Web servers.

Cross-Certification Trusts

In a cross-certification trust, a CA in one organization’s root CA hierarchy issues a subordinate CA certificate to a CA in another organization’s CA hierarchy. The following figure illustrates a cross-certification hierarchy.

Cross-Certification Trust

A cross-certification trust:

• Provides interoperability between businesses and between products. When cross-certification is implemented, the certificates are logically chained to the trusted root CA of the organization that is evaluating the presented certificate.

• Joins disparate PKI domains. You can issue a Cross Certification Authority certificate from any CA in your organization’s hierarchy to any CA in a partner organization’s CA hierarchy.

• Assumes complete trust of a foreign CA hierarchy. Cross-certification does not enforce any constraints on the certificates that a partner organization issues. You must implement qualified subordination to implement constraints on those certificates.