P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
158 PUBLICKEYINFRASTRUCTURE(PKI)popular PKI construction topologies: the hierarchical PKI
and the mesh PKI.PKI Components and Users
A PKI is often built from three basic functional compo-
nents: the certification authority (CA), the registration
authority (RA), and the repository. A CA is the primary
component of the PKI, known by its name and its public
key. A CA comprises hardware, software, and the people
who operate it. A CA issues certificates, maintains certifi-
cate status information and issues CRLs, and publishes
certificates and CRLs. A CA must protect the private key
or keys used to sign certificates and CRLs, using physical,
procedural, and technical controls.
An RA verifies certificate contents prior to certificate
issuance, and it may also assume some of the responsi-
bility for certificate revocation decisions. Certificate con-
tents may be verified by information presented to the RA,
such as a driver’s license. They may also reflect data from
a company’s human resources department. A CA is likely
to work with multiple RAs, because different RAs may be
needed for different users groups.
A repository distributes certificates and CRLs. It ac-
cepts certificates and CRLs from one or more CAs and
makes them available to parties that need them, and it is
usually designed to maximize performance and availabil-
ity. Repositories are often duplicated to maximize avail-
ability, increase performance, and add redundancy.
A PKI supports two types of users: certificate hold-
ers and relying parties. A certificate holder is the subject
of certificate, and it holds the corresponding private key.
The CA issues a certificate to the certificate holder. In
many circumstances, the certificate holder requests the
certificate directly from the CA or through the RA. Certifi-
cate holders may need to interact with the repository to
obtain their own certificate but do not regularly interact
with it. Certificate holders may include their own certifi-
cate in transactions.
A relying party uses the public key in a certificate to
verify signatures, encrypt data (key transport), or perform
key agreement. A relying party identifies one or more trust
anchor, verifies signatures on certificates and CRLs, ob-
tains certificates and CRLs from a repository, and con-
structs and validates certification paths. A relying party
regularly interacts with repositories, but it has no inter-
actions with RAs.PKI ARCHITECTURES
The most basic PKI architecture is a single CA that pro-
vides all the certificates and CRLs for a community of
users. In this configuration, all users trust the CA that is-
sued their certificate. By definition, new CAs cannot be
added to the PKI, and all certificates are user certificates.
The users accept only certificates and CRLs issued by their
CA. Although the simplest to implement, this architecture
does not scale easily to support large or diverse user com-
munities. The single CA PKI presents a single point of
failure. Compromise of the CA invalidates the trust point
information and all certificates that have been issued in
this PKI. Every user in the PKI must be informed aboutthe compromise immediately, or they may establish secu-
rity based on unreliable information. To reestablish the
CA, all certificates must be reissued and the new trust
point information must be distributed to all the users. To
overcome these deficiencies, two architectures are widely
employed: the hierarchical PKI and the mesh PKI. (Recall
that Figure 3 illustrates these topologies.)Hierarchical PKI
The hierarchical PKI is the traditional PKI architecture.
All users trust the same centralroot CA. With the excep-
tion of the root CA, all of the CAs have a single superior
CA. CAs may have subordinate CAs or issue certificates
to users or both. A single certificate represents each trust
relationship, making certification path construction sim-
ple, obvious, and deterministic. The certification paths are
usually short. The longest path is equal to the depth of the
tree.
Superior CAs may impose restrictions upon the subor-
dinate’s actions. These restrictions could be maintained
through procedural mechanisms or imposed through the
certificates themselves. In the latter case, the CA certifi-
cate will contain additional information to describe the
restrictions. For example, the Hawk HQ CA could issue a
certificate to a subordinate Hawk Legal CA that requires
valid certificates to contain a particular prefix in all sub-
ject names, which clearly indicates employment in the le-
gal department.
When users are portioned into smaller groups, each
served by a different CA in the hierarchical PKI, it is eas-
ily handle the compromise of a single CA, as long as it
is not the root CA. If a CA is compromised, its superior
CA simply revokes its certificate. Once the CA has been
reestablished, it issues new certificates to all of its users.
The superior issues a new certificate to the CA, contain-
ing the new public key, bringing it back into the hierarchy.
During the interim, transactions between any two users
outside the compromised part of the PKI can proceed. Of
course, users in the compromised part of the hierarchy
lose all services.
On the other hand, the compromise of the root CA has
the same impact as in the single CA architecture. It is crit-
ical to inform all the users in the hierarchical PKI that
the root CA has been compromised. Until the root CA is
reestablished, issues new certificates to its subordinates,
and distributes the new trust point information, users can-
not use the PKI to establish secure communications. In
comparison to the compromise of the single CA, the root
CA will have to reissue a much smaller number of cer-
tificates to resume operations. The root CA usually oper-
ates offline, significantly reducing the likelihood of such
a compromise.Mesh PKI
The mesh PKI architecture is the primary alternative to
a hierarchy. Multiple CAs provide PKI services, but the
CAs are related through peer-to-peer relationships. Each
user trusts a single CA; however, the trusted CA is not the
same for all users. Generally, users trust the CA that is-
sued their certificate. CAs issue certificates to each other;
a pair of certificates describes their bidirectional trust