Computer Communications 24 (2001) 1460±1471

www.elsevier.com/locate/comcom
Tutorial

Technological infrastructure for PKI and digital certi®cation

Ray Hunt*
Department of Computer Science, University of Canterbury, Private Bag 4800, Christchruch, New Zealand
Received 30 August 2000; revised 19 December 2000; accepted 20 December 2000

Abstract
Secure E-Commerce and VPN technology is only possible with the use of appropriate security systems such as encryption, digital
signatures, digital certi®cates, public/private key pairs, non-repudiation, and time-stamping. A PKI comprises a system of certi®cates,
certi®cate authorities, subjects, relying partners, registration authorities, and key repositories that provide for safe and reliable E-business.
This paper discusses these key technologies focusing particularly on recent standardisation as well as looking at some of the criticism and
challenges to its widespread operation in the industry. q 2001 Elsevier Science B.V. All rights reserved.
Keywords: Symmetric and asymmetric encryption; VPN; Dif®e±Hellman key exchange; Digital signature; X.509; IPSec; CA; RA; TTP; CRL; PKI; SPKI;
PKIX; Digital certi®cate; Key management

1. Introduction the different areas to which PKI can be applied to solve

existing problems and examines a range of current
Traditionally, information systems have been largely criticisms and challenges.
centralised with administration under the control of a single
management domain. Security mechanisms to support such
2. PKI background and standards developments
systems re¯ect this structure and this has lead to the deploy-
ment of in¯exible and non scalable security mechanisms
E-business is demanding a secure way to transmit ®nan-
administered under a single security policy. However,
cially or legally sensitive data. The three main problems
with the rapid growth of the Internet, the rise of E-business
faced by users of the Internet are integrity, authentication
and the trend towards decentralisation, situations arise in
and non-repudiation. Integrity requires the receiver be able
which entities in multiple domains need to communicate
to verify that the message has not been modi®ed in transit,
with each other securely. Public key cryptography can
authentication enables each party to a communication to be
play an important role in providing needed security services
sure of the identity of the other (i.e. message cannot be
including con®dentiality, authentication, digital signatures
forged and prevents an attacker masquerading as a legiti-
and integrity. One important factor critical to the operation
mate participant), while non-repudiation prevents the sender
of a global public key cryptosystem on the Internet is a
from denying that they sent the message. Cryptography
reliable and practical means of publishing the public keys
holds the most promise as a solution to these problems
and Public Key Infrastructure or PKI in its most simple form
and public key cryptography in particular appears to be
is a system for publishing public keys. PKI can be used to solve
best suited to ful®ll these requirements.
many problems, however there are still several problems and
Securing business and communications over computer
risks involved in its use as well as organisational and manage-
networks can be likened to an electronic equivalent of signing
ment issues for which solutions are still evolving.
a letter, sealing it an envelope and registering it with the Post
This paper provides a brief outline of the basic concepts
Of®ce. The signature proves authenticity, the sealed envelope
and principals involved in the operation of a PKI including
provides con®dentiality and registration guarantees delivery.
issues such as how a PKI operates, its characteristics and
Public key cryptography was conceived in 1976 by Dif®e
what problems need to be addressed before the use of PKI
and Hellman [3] and in 1977, Rivest, Shamir and Adleman
becomes more widespread. This paper also brie¯y looks at
designed the RSA Cryptosystem [35], the ®rst public key
system. Each public key cryptosystem has its own technical
* Tel.: 164-3-3642347; fax: 164-3-3642999. features, however they all share the property that given an
E-mail address: ray@cosc.canterbury.ac.nz (R. Hunt). encryption key it is computationally infeasible to determine
0140-3664/01/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved.
PII: S 0140-366 4(01)00293-6
 R. Hunt / Computer Communications 24 (2001) 1460±1471
the decryption key and vice versa. This lets a user, Alice
publish her encryption key so that anyone can use her public
key to encrypt a message that only Alice can decipher with her
private key. Theoretically, no con®dential information needs
to be exchanged between participants before secure commu-
nication is possible. The problem is that everyone has access to
Alice's public key and that even though the communication
between Alice and another user, Bob is private, the message
cannot be authenticated. This shows that public key crypto-
graphy on its own, is not enough. If the conditions for
traditional paper based commerce are to be reproduced in
the electronic environment, the following are required:
² Security policies to de®ne the rules under which crypto-
graphic systems should operate.
² Products to generate, store and manage certi®cates and their
associated keys.
² Procedures to dictate how the keys and certi®cates should
be generated, distributed and used.
In other words, a trusted and authenticated key distribution
infrastructure is necessary to support the use of public keys on
a public network such as the Internet. Recent efforts in stan-
dardisation have seen developments on a number of fronts.
2.1. Evolution of PKI standards
The ITU-T Recommendation X.509 provides a very useful
basis for de®ning data formats and procedures related to the
distribution of public keys via certi®cates that are digitally
signed by CAs. X.509 does not however include a pro®le to
specify the supporting requirements for many of the certi®cate
data structure's sub-®elds, extensions or for some data values.
The standards effort produced an outline for PKI of X.509
Version 3 certi®cates as well as Version 2 Certi®cate Revo-
cation Lists (see Section 3.2.3). The Internet PKI pro®le
went through eleven draft versions before becoming ªInter-
net X.509 Public Key Infrastructure Certi®cate and CRL
Pro®leº [23]. Other pro®les have been developed for parti-
cular algorithms to make use of Ref. [23].
The development of the PKI management protocols has
gone though a number of iterations. PKI [24] was developed
to specify a message protocol to be used between entities in
a PKI. The need for an enrolment protocol and the prefer-
ence to use PKCS [16] message format as the certi®cate
request syntax lead to two parallel developments. 1
1
The Certi®cate Request Syntax was developed in the S/MiMe WG
which used PKCS #10 [16] as the certi®cation request message formate.
Certi®cate Request Message Format [25] draft was also developed but in
the PKIX WG. It was to de®ne a simple enrolment protocol that would work
for the PKI [24] enrolment protocols, but it did not use PKCS#10 [16] as the
certi®cate request message format. Then, the Certi®cate Management
Protocols [24] and Messages [4] were developed to de®ne an extended
set of management messages that ¯ow between the components of the
Internet PKI. These, combined with CMS [4] allowed the use of an existing
protocol (S/MIME) as a PKI management protocol, without requiring the
development of an entirely new protocol such as CMP [24]. It also included
in PKCS#10 [16]as the certi®cate request syntax.
1461
Development of the operational protocols has been more
straightforward. Two documents for LDAP (Lightweight
Directory Access Protocol) have been developed Ð one
for de®ning LDAPv3 as an access protocol to repositories
[17,20] and one for storing PKI information in an LDAP
directory [32]. Using FTP and HTTP to retrieve certi®cates
and CRLs from PKI repositories is speci®ed in Ref. [31].
3. Public key infrastructure
In its simplest form, a PKI is a system for publishing the
public keys used in public key cryptography. PKI provides
the core framework for a wide variety of components, appli-
cations, policies and practices to combine and achieve the
three principal security functions (integrity, authentication
and non-repudiation). A PKI is a combination of hardware
and software products, policies and procedures. It provides
the basic security required to carry out E-business so that
users who do not know each other or are widely distributed,
can communicate securely through a chain of trust. Digital
certi®cates are a vital component in the PKI infrastructure as
they act as `digital passports' by binding the user's digital
signature to their public key. 2
3.1. Components of a PKI
A PKI consists of:
² A Security Policy.
² Certi®cate Authority (CA).
² Registration Authority (RA).
² Certi®cate Repository and Distribution System.
² PKI-enabled Applications.
3.1.1. Security policy
A security policy sets out and de®nes an organisation's
top level direction on information security as well as the
processes and principles for the use of cryptography. Typi-
cally it will include statements on how the organisation will
handle keys and valuable information and will set the level
of control required to match the levels of risk.
Some PKI systems are operated by Commercial Certi®-
cate Authorities (CCAs) or Trusted Third Parties (TTPs)
and therefore require a Certi®cate Practice Statement
(CPS) [1]. This is a detailed document containing the opera-
tional procedures on how the security policy will be
enforced and supported in practice. It typically includes
vital speci®cations on how the CAs are constructed and
2
Only the user holds their private key. The user's computer generates the
public and private key pair. The public key is then send to the CA where it is
veri®ed and a digital certi®cate is issued. This certi®cate is then sent back to
the user and stored. Copies of this certi®cate can then accompany transac-
tions from which the (certi®ed) public key is available. The fact that a
cryptographically strong private key may be kept on a computer protected
by a cryptographically weak password is a security issue that needs careful
consideration.
1462 R. Hunt / Computer Communications 24 (2001) 1460±1471
operated, how certi®cates are issued, accepted and revoked,
how keys will be generated, registered and certi®ed, where
they will be stored and how they will be made available to
users. The Electronic Commerce Promotion Council of
Japan (ECOM) came out with some guidelines, which
form the basis for the general management requirements
for the operation of a CA, the requirements for speci®c
services conducted by CAs as well as facility and system
requirements [10]. For more speci®c information of what a
CPS should contain, VeriSign, a leading provider of Internet
trust services, have also publicised their CPS [39].
3.1.2. Certi®cation authority (CA)
The CA is an entity which issues and revokes certi®cates.
An in-house server or a TTP such as Entrust, Baltimore or
VeriSign, can provide a CA function. A CA provides the
trust basis for a PKI as it manages public key certi®cates for
their whole life cycle.
The CA will:
² Issue certi®cates by binding the identity of a user or
system to a public key with a digital signature.
² Schedule expiry dates for certi®cates.
² Ensure certi®cates are revoked when necessary by
publishing CRLs.
When implementing a PKI, an organisation can either
operate its own CA or use the services of a Commercial
CA or TTP.
While the principles of PKI are the same there are
currently two major commercial implementation models
which depend upon who the CA is:
1. Private CA Ð vendors sell a complete PKI system to an
organisation which then becomes its own CA and is
responsible for the issuing and management of certi®-
cates. Examples include RSA's Keon, IBM's Trust
Authority, Baltimore's Unicert and Entrust's PKI.
2. Public CA Ð certi®cates are purchased from a public
CA organisation as required. The most common example
of this approach is VeriSign.
The fundamental difference between these two models is
that the later sells commercial digital certi®cates while the
former sells the software for the user to produce their own
certi®cates. On each of the respective web sites are a
number of white papers claiming the advantages of these
models [13,38].
Generally for a large organisation it is more cost effective to
operate a private CA as it offers more ¯exible control and once
the system is in place the economies of scale allow extra
certi®cates to be produced and managed very cheaply. For a
small organisation it is likely to be advantageous to purchase
individual certi®cates as such organisations are unlikely to
have the infrastructure required to deploy such a large system
nor the volume necessary to produce cheap certi®cates.
There is also a hybrid-outsourcing model where an orga-
nisation outsourcers its private CA operations to a public
CA in a similar manner to which PBXs are hosted at telco
premises (Centrex). An example of this infrastructure is the
Equifax system [37].
3.1.3. Registration authority (RA)
An RA provides the interface between the user and the
CA. It authenticates the identity of the users and submits the
certi®cate request to the CA. The quality of this authentica-
tion process determines the level of trust that can be placed
in the certi®cates. For example, if all an RA requires an
e-mail address and a name Ð before it issues a certi®cate
Ð the level of trust that should be placed in that certi®cate
would be considerably lower than if more stringent registra-
tion procedures were required.
Registration is distinct from the process of creating, sign-
ing and issuing certi®cates. For example a Human
Resources Department may manage the RA function
while an Information Technology Department manages
the CA. A separate RA also makes it harder for any single
department to subvert the security of the system. Organisa-
tions can choose to have registration handled by a separate
RA, or included as a function of the CA.
3.1.4. Certi®cate repository and distribution system
The Certi®cate Repository provides a mechanism for
storing keys, certi®cates and Certi®cate Revocation Lists
(CRLs), which is usually based on an LDAP-enabled direc-
tory service. Key recovery is an advanced function required
to recover data or messages when a key is lost and a PKI
may provide such an automated key recovery service.
Certi®cates can be distributed in a number of ways
depending on the structure of the PKI environment. For
example, certi®cates may be distributed by the users them-
selves or through an LDAP directory service.
3.1.5. PKI-enabled applications
A PKI is a means to an end Ð providing the security
framework by which PKI-enabled applications can be con®-
dently deployed to achieve the end bene®ts. Fig. 1 shows the
relationship between some applications and infrastructure,
and their related standards. Examples include:
² Document exchange between web servers and remote
access clients.
² E-mail and Groupware (PGP, S/MIME, Lotus Notes
Groupware).
² Online banking, shopping and credit card transactions
over the Internet.
² Virtual Private Networks (VPNs) operating with PPTP,
IPSec, etc.
3.2. Operations of PKI
The main PKI functions are shown in Table 1. These
 R. Hunt / Computer Communications 24 (2001) 1460±1471 1463

Di gi t al l y E- mai l Onl i ne
Si gned Banki ng
Gr oupw ar e VPN
Code and Onl i ne
Fi l es Shoppi ng

St andar ds
S/ MI ME SSLv3 .0 I PSec
t hat r el y
TLSv1 .0 PPTP on a PKI
SET

St andar ds
X.5 09 PKI X PKCS t hat def i ne
t he PKI

Fig. 1. PKI security architecture [36].

include Ð registration, issuing and revoking certi®cates,
creating and publishing CRLs, storing and retrieving certi-
®cates and CRLs, as well as key lifecycle management.
Some of the enhanced functions include time-stamping
and policy-based certi®cate validation.
These functions can be described in terms of three basic
PKI infrastructures:
² Certi®cation is the process of binding a public key value
to an entity.
² Validation is the process of verifying that a certi®cate is
valid and revoking where necessary.
² Key management Ð updating, backing up, archiving etc.
3.2.1. Certi®cation
Certi®cation is the fundamental function of all PKIs
and it is the means by which the public keys and infor-
mation pertaining to those keys are published. PKI
communicates this information through a certi®cate.
Fig. 2 shows the information contained in a basic certi-
®cate. If a user, Alice wishes to communicate with
another user, Bob using a public key cryptosystem,
Alice must have direct knowledge of Bob's public key.
With a PKI, Alice only needs to have direct knowledge
of the CA's public key and the CA would issue an
identity certi®cate for Bob's public key. If Alice and
the CA are distinct entities, how Alice trusts the CA
would depend on how much con®dence she has in
using the CA's certi®cates for secure communications.
A CA might have different classes of certi®cates with
each class providing a designated level of trust.
For example to overcome these inherent limitations
VeriSign has introduced four different levels of certi®cate
[40] (each with different cost structures) corresponding to
the degree of authentication required. See Table 2.
In addition to the content and authenticity of a transac-
tion, the exact time of the transaction can be important. For
example, a transaction may have to be submitted within a
speci®ed timeframe to be valid. The solution to having
trusted transactions is to combine digital signatures with a
time-stamping service. (See Section 5.5)

Table 1
Public Key Infrastructure (PKI) Functions

Function Description Implementation

Registering users Collect user information, verify Function of CA, or separate RA

Issuing certi®cates
Revoking certi®cates
Storing and retrieving
certi®cates and CRLs
Policy-based certi®cate
path validation
Time-stamping
Key lifecycle management
identity
Create certi®cates in response to
user or administrator request
Create and publish Certi®cate
Revocation Lists (CRLs)
Make certi®cates and CRLs
available to authourised users
Impose policy-based constraints
on certi®cate chain, and validate
if all constraints are met
Time-stamp each certi®cate
Update, archive and restore keys
Function of the CA
Administrative software
associated with the CA
Repository for certi®cates and
CRLs in secure replicated
directory service accessible via
LDAP
Function of the CA
Function of the CA or a
dedicated Time Server (TS)
Automated in software or
performed manually
1464 R. Hunt / Computer Communications 24 (2001) 1460±1471
Fig. 2. Basic Structure of a Digital Certi®cate.
3.2.2. CA hierarchy
It is impractical to have a single universal CA and most
PKIs permit CAs to certify other CAs. Fig. 3 shows a
general hierarchy of how CAs operate. In the previous
example, if Alice and Bob belongs to different CAs, for
Alice to communicate with Bob, she must either have
knowledge of Bob's public key or Bob's CA's public key
(so she can obtain the key from Bob's CA) or have her CA
issue a certi®cate for that key (her CA would then try to ®nd
Bob's public key through other CAs). There may be an
arbitrary number of CAs between Alice and Bob (through
E, B, A, C and F or just through E to F), and Alice would
have to verify the certi®cation of each CA until she obtains
Bob's certi®cation. This process is called certi®cation path
validation. 3 Different PKIs arrange their CAs in different
hierarchies or they may even have arbitrary or bilateral
structural agreements. An example of a PKI that does not
impose any restrictions on its hierarchy is the PGP PKI. This
is further discussed in Section 4.
The scalability of a PKI depends on the relationship
between its CAs. A problem here is that CAs may allocate
trusts differently and this problem increases as the certi®ca-
tion path grows. The certi®cation path also runs the risks of
becoming too long. It is estimated that in a global PKI, the
average certi®cation path length would be between six
and seven [15]. Path discovery and trust delegation (one
CA may de®ne its trust different from another) is dif®cult
to achieve across company and/or geographical bound-
aries. The dominant hierarchy is top down, but it has
the problem that all users must trust the root CA and
since so many paths pass through the root CA, it is
vulnerable to attack.
The best known hierarchical certi®cation path processing
architectures are those maintained by PKI service organisa-
tions such as Entrust, Baltimore and VeriSign. Typically, in
such a hierarchy:
² There is a single root at the top.
² The root certi®es public primary certi®cation authorities
(PCAs), which issue, suspend, and revoke certi®cates for
all CAs within their hierarchy.
² PCAs certify CAs. PCAs may also cross-certify with
3
The implementation and operation of such a system is not a trivial
exercise. It requires strict adherence to standards and compatible protocols.
To date most pilot systems operate with a single (often proprietary) CA.
PCA-like entities in other vendors' PKIs as demonstrated
in Fig. 3.
² CAs authorise subordinate CAs, which belong to the PKI
service company or the customer.
² At the bottom of the hierarchy can be local registration
authorities (LRAs) that evaluate certi®cate applications
on behalf of the root, PCA, or CA that issues the
certi®cates.
If a user does not already trust the CA that signed a
certi®cate, they can search upward through the hierarchy
for a trusted CA that has certi®ed the public key of the
CA in question. Further, a CA can issue another CA with
a certi®cate that allows the other CA to issue certi®cates,
which will be recognised by the ®rst CA. 4 Cross-certi®ca-
tion works directly, without a third party.
It can make sense to implement both hierarchical and
cross-certi®cation in a single security domain, for different
purposes or at different times. For example, a hierarchical
system based on a TTP may be necessary when setting up or
expanding a PKI, but the bulk of day-to-day interoperability
may be accomplished via cross-certi®cation.
Policy-based certi®cate path validation is still an evolving
part of CA functionality. Policy mapping matches one CA's
policy to another, allowing CAs to interoperate if they
support similar but not necessarily identical policies. Alter-
natively it may be desirable to prohibit policy mapping, so
that the path will be validated only if the CAs have identical
policies. This is the subject of ongoing research and
development.
3.2.3. Validation and revocation
The information in a certi®cate can change over time and
a certi®cate user needs to validate that the certi®cate's data
is current. Users can either:
² Ask the CA about a certi®cate's validity every time it is
used (online validation).
² Request the CA to include a validity period in the
certi®cate (of¯ine validation).
Closely related to the issue of validation of certi®cates is
4
For example the British Medical Association might grant registration
rights to the New Zealand Medical Association such that the later could
issue doctors' registration certi®cates on the basis of trust between the two
associations.
 R. Hunt / Computer Communications 24 (2001) 1460±1471
Table 2
Classes of Digital Certi®cates available from VeriSign
VeriSign Class 1 Individual Certi®cates enhances the
security of some applications by assuring that a
certi®cate's subject and e-mail address are included
within VeriSign's repository. Class 1 Certi®cates
provide assurances that communications originate from
a particular source but do not provide proof of identity.
VeriSign Class 2 Individual Certi®cates provide a
reasonable level of assurance of a subscriber's identity.
Enterprise customers using OnSite SM validate certi®cate
applicants by checking their identities against enterprise
local records or Trusted Third Parties (TTP).
VeriSign Class 3 Individual Certi®cates provides a
higher level of assurance by validating the identity via
in-person presentation of identi®cation credentials or
other enhanced procedures. These certi®cates are
typically suitable for applications such as electronic
banking and contracting.
VeriSign Class 3 Organisational (Server) Certi®cates
provide assurances to an entity trying to authenticate a
Website. Validation of certi®cate applicants includes
comparison of certi®cate application information to
information held by TTPs or of®cial records provided by
the applicant and supplemented by independent
contacts.
certi®cation revocation. A certi®cate should be revoked
when it is suspected that it has been compromised. If a
certi®cate is validated online with the CA, the CA can
simply state that the certi®cate is no longer valid. With
of¯ine validation, the most common way is to use CRLs.
A CRL is a list of certi®cates that have been revoked before
their scheduled expiration date. There are several reasons
why a certi®cate might need to be revoked. For example, the
key speci®ed in the certi®cate might have been compro-
mised or the user speci®ed in the certi®cate may no longer
have authority to use the key. An employee may have
resigned or changed names.
Fig. 3. Certi®cate path validation via a path of trust in the CA hierarchy.
1465
When verifying a signature, the relevant CRL is exam-
ined to ensure that the signer's certi®cate has not been
revoked. Whether it is worth the time to perform this
check depends on the importance of the signed document.
A CRL is maintained by a CA, and it provides information
about revoked certi®cates that were issued by that CA.
CRLs only list current certi®cates, since expired certi®cates
should not be accepted in any case. When a revoked certi-
®cate's expiration date occurs, that certi®cate can be
removed from the CRL.
CRLs can also be distributed in one of two ways. In the
`pull' model, veri®ers download the CRL from the CA, as
needed. In the `push' model, the CA sends the CRL to the
veri®ers at regular intervals. Some systems use a hybrid
approach where the CRL is pushed to several intermediate
repositories from which the veri®ers may retrieve it as
needed. Although CRLs are maintained in a distributed
manner, there may be central repositories for CRLs, such
as, network sites containing the latest CRLs from many
organisations. For example a bank might require an
in-house CRL repository to make CRL searches on every
transaction feasible.
There are two major problems with the CRL approach:
Firstly, time-granularity relates to what happens between
the time when a CA receives noti®cation that a certi®cate
should be revoked and when it publishes its next CRL. Since
the revoked certi®cate will only appear on the next CRL,
any users checking the current CRL will not know of the
revocation and assume that the certi®cate is still valid. A
solution that has been proposed to solve this problem is to
issue a list of certi®cates that have been revoked since the
last CRL. This list of certi®cates is called a delta-CRL.
Delta-CRLs are much smaller than a CRL and can be issued
more frequently.
Secondly, when a CRL gets too large, it may be dif®cult
for users to retrieve it, particularly when bandwidth access
to a CA is limited. There have been several solutions
1466 R. Hunt / Computer Communications 24 (2001) 1460±1471
proposed such as dividing the CRL into smaller sections (for
example grouped by reason for revocation). At best this is
only a temporary solution to the problem and research is still
being carried out.
The PKIX recommendation does not require CAs to issue
CRLs [18]. On-line methods of revocation noti®cation may
be applicable in some situations as an alternative to CRLs.
PKIX de®nes an Online Certi®cate Status Protocol that
facilitates on-line checking of the status of certi®cates
[7,30].
3.2.4. Key management
The PKI performs functions, such as issuing a certi®cate
and listing a certi®cate on a CRL in response to a current
request. In contrast, key lifecycle functions, such as updat-
ing, backing up, and archiving keys, are performed
routinely. Each user is likely to have a number of keys
that require lifecycle management. For example, users
typically have at least one key pair for each secure
application (e.g. e-mail, desktop ®le encryption, VPN).
Some applications use several key pairs for different
purposes, such as digital signatures, bulk encryption, and
authentication.
3.2.4.1. Updating keys. New keys are usually issued at
regular intervals so as to reduce the exposure from keys
that have been unknowingly compromised.
3.2.4.2. Backing up keys. Users frequently forget the
passwords that protect their private keys Ð or they may
lose the keys, for example, through a disk crash or virus
attack. The company should be able to restore the keys to
the user.
3.2.4.3. Archiving keys. When employees leave the
company, their keys must be invalidated, while retaining
the keys in order to access previously encrypted ®les and
messages. Keys used for digital signatures may be retained
for as long as the signed documents exist so that signatures
can be veri®ed. Some organisations archive encryption keys
but not signing keys, since the availability of archived
signing keys could invite abuse via identity impersonation.
3.2.4.4. Key expiry. To guard against a long-term
cryptanalytic attack, every key must have an expiration
date. The time to expiration must therefore be much
shorter than the expected time for cryptanalysis. That is,
the key length must be long enough to make the chances
of cryptanalysis before key expiration extremely small. The
validity period for a key pair may also depend on the
circumstances in which the key is used. The appropriate
key size is determined by the validity period, together
with the value of the information protected and the
estimated strength of an expected attacker. In a certi®cate
the expiration date of a key is typically the same as the
expiration date of the certi®cate.
A signature veri®cation program should check for expira-
tion and should not accept a message signed with an expired
key. This means that when one's own key expires, every-
thing signed with it will no longer be considered valid.
There may be cases in which it is important that a signed
document be considered valid for a much longer period of
time and time stamping is therefore necessary.
If a private key is lost or destroyed but not compromised,
messages can no longer be signed or decrypted Ð but
anything previously signed with the lost key is still valid.
The key must be placed on a CRL to prevent any illegiti-
mate use should the key be found or recovered by an
attacker. Loss of a private key can happen, for example, if
the smart-card used to store keys is lost, or if the disk on
which the key is stored is damaged.
4. Use of PKI with PGP
There are a number of important protocols, which will
bene®t from the use of PKI Ð these include S/MIME, PGP
and TLS1.0 (old SSLv3). One of these Ð PGP (Pretty Good
Privacy) is brie¯y discussed here.
PGP is a public key cryptography program designed for
use with Internet e-mail and created by Zimmermann [41].
It is the world's defacto standard for e-mail encryption with
over six million users. PGP is a hybrid cryptosystem made
up of four cryptographic elements Ð a symmetric encryp-
tion cipher (IDEA), an asymmetric encryption cipher
(RSA), a hash function (MD5) and a random number
generator. Each of these four elements are subject to a
different form of attack [14]. PGP users each maintain
their own list (keyring) of the public keys of the people
they communicate with. This keyring is signed by the user's
own private key as a precaution against tampering. PGP
allows users to exchange keyrings and a user can add
another key to the keyring, assigning one of the following
four values to this new key:
² Completely trusted Ð if any other key is signed by this
key, then add the new key to the keyring.
² Marginally trusted Ð a key signed by this key must also
be signed by one or more keys before it is added to the
keyring.
² Untrusted Ð this key should not be used in determining
whether other keys can be added to the keyring or not.
² Unknown Ð the level of trust for this key cannot be
determined.
These values allow a user to assign a level of trust and the
user is able to tune the PGP's criteria for accepting a key.
For example if there are four users, Alice, Bob, Eve and
Chris. Bob knows Alice personally and has her key, while
Chris knows Eve and has her key. On day, Chris and Bob
met and decided to exchange their keys.
At this point, Alice's keyring contains keys for Bob,
Bob's keyring contains keys for Alice and Chris, Chris's
 R. Hunt / Computer Communications 24 (2001) 1460±1471
keyring contains keys for Bob and Eve and Eve's keyring
only contains the key for Chris.
One day, Bob decides to exchange keyrings with Alice
and Chris. He is able to exchange keyrings with Chris
securely because he knows Chris's key. Since Alice
knows Bob's key, when Bob sends her his keyring, she is
able to verify that it is indeed Bob's keyring. Alice now has
the keys for Bob, Chris and Eve. Alice can now commu-
nicate reasonably securely with Chris since Bob obtained
Chris's key directly before giving it to her. However, if
Alice wants to communicate with Eve, she is relying on
Chris. This effectively implies a chain of trust. Because
Alice trusts Bob, she ends up trusting Chris (someone she
never met). Alice also has no way of knowing which keys
came from Chris unless Bob tells her explicitly.
4.1. PGP PKI
As users trade keyrings, they build up a web of trust and
this is the simplest form of a PKI. Each user, effectively
acting as their own root CA, is able to assign a level of
trust. The user's public key, with the keyring included,
could also be considered to be a type of user's certi®cate.
This simplicity, together with the fact that there is no expli-
cit infrastructure (the only infrastructure needed is e-mail)
to maintain, allowed PGP to gain acceptance on the Internet.
However, in applications where strong authentication is
needed, the PGP±PKI is not acceptable.
4.2. Shortcomings of PGP±PKI
The web of trust method forces users to trust someone's
entire keyring even if the user only really trusts the owner of
the keyring. In the example above, Alice trusts Bob, and
because she trusts Bob and his entire keyring, she is also
forced to trust Chris. Another problem related to the web of
trust method is that if one user is fooled into believing some-
one else's identity, any other users will also be fooled into
believing that person's identity by trusting the keyring of the
user who was originally fooled.
A PGP certi®cate contains only an e-mail address, a
public key and a degree of trust attribute. Since an e-mail
address can easily be forged, PGP does not provide strong
authentication of a person's identity. Also PGP's use of
e-mail addresses prevents its users from having any degree
of anonymity. Another issue with PGP certi®cates is that
they are not extensible and currently there is no coherent
method for validating, revoking PGP certi®cates (currently
performed by word-of-mouth) or recovering lost keys.
These problems, and the fact that PGP was designed only
for securing e-mail prevents PGP from being used for appli-
cations beyond causal e-mail communication.
4.3. An application of PKI
To date, use of PKI has not been widespread due to
reasons such as cost, complexity as well as a lack of
1467
quali®ed resources and a critical mass of businesses. It
would seem that PKI would eventually become more wide-
spread when it ®nally ®nds a solution to the problems
mentioned above. In the meantime, companies are imple-
menting PKIs as a practical way to solve technological
problems such as managing VPNs.
VPNs are now standardising on the IP Security (IPSec)
protocol [21]. A critical aspect of IPSec is how keys are
exchanged to authenticate each endpoint of the encrypted
tunnel. The protocol for doing this is called Internet Key
Exchange (IKE) [22] and supports manually entering
pre-shared keys into both hosts, by the use of a secure
DNS and by a PKI CA. Manually con®guring shared secrets
on every router and ®rewall is giving way to central
management through a CA. Con®guring VPN devices [19]
to authenticate via a CA provides a scalable, centrally
managed solution to revoking and reassigning the certi®-
cates used to create a trusted connection. This is just one
example of the many services that a PKI can provide.
5. PKI working group activities
There are two key IETF working groups focused on PKI
standards and implementations.
The Simple Public Key Infrastructure (SPKI) working
group 5 is developing Internet drafts for public key certi®cate
formats, signature formats and key acquisition protocols.
SPKI is intended to provide mechanisms to support security
over a range of protocols (e.g. IPSec) and applications,
which may require public key certi®cates such as encrypted
e-mail, web documents and electronic payment systems.
Two important RFCs developed under SPKI are included
in Refs. [33,34].
The PKIX working group 6 has developed recommended
standards covering ®ve signi®cantly different sections [18]:
² Pro®les of the X.509v3 certi®cate standards and the
X.509v2 CRL standards for the Internet.
² Operational protocols, in which relying parties can obtain
information such as certi®cates or certi®cate status.
² Management protocols, in which different entities in the
system exchange information needed for proper manage-
ment of the PKI.
² Certi®cate policies and certi®cate practice statements,
covering the areas of PKI security not directly addressed
in the rest of PKIX.
² Time-stamping and data certi®cation services, which can
be used to build services such as non-repudiation.
5.1. X.509v3 pro®les
X.509v3 certi®cates are complex data structures as they
5
www.ietf.org/html.charters/spki-charter.html.
6
www.ietf.org/html.charters/pkix-charter.html.
1468 R. Hunt / Computer Communications 24 (2001) 1460±1471

offer a variety of extensions, which can take on a wide range
of options. This provides considerable ¯exibility, which
allows the X.509v3 certi®cate format to be used with a
many applications. Unfortunately, this same ¯exibility
makes it extremely dif®cult to produce independent imple-
mentations that will actually interoperate. To build an Inter-
net PKI based on X.509v3 certi®cates, the PKIX working
group developed a pro®le of the X.509v3 speci®cation.
A pro®le of the X.509v3 speci®cation is a description of
the contents of the certi®cate together with mandatory,
optional or denied extensions. PKI of Ref. [23] provides
such a pro®le of X.509v3 and recommends a range of values
for various extensions. To promote interoperability, it is
necessary to constrain the choices an implementer supports.
In addition to pro®ling the certi®cate and CRL formats, it
is necessary to specify particular Object Identi®ers (OIDs)
for certain encryption algorithms, since there are a variety of
OIDs registered for certain algorithm suites. PKIX has
produced two documents Ð [6,27], which provide
assistance on the implementation of speci®c algorithms.
Some countries are in a process of updating their legal
frameworks in order to regulate and incorporate recognition
of signatures in electronic format. Many of these frame-
works introduce certain basic requirements on certi®cates,
(Quali®ed Certi®cates) for the support of these types of
`legal' signatures. There is a need for a speci®c certi®cate
pro®le providing standardised support for related issues
such as a common structure for expressing identities of
certi®ed subjects (unmistakable identity). The PKIX work-
ing group has adopted a re®nement of Ref. [23] that further
pro®les PKIX certi®cates into quali®ed certi®cates. This
work is described in Ref. [8].
5.2. Operational protocols
Certi®cates and CRLs can be delivered by protocols such
as LDAP, HTTP, FTP and X.500. Operational protocols that
facilitate certi®cate delivery are de®ned in Refs. [7,28±31].
5.3. Management protocols
Management protocols are needed to support online inter-
actions between PKI user and management entities. For
example, a management protocol might be used between a
CA and a client with whom a key pair is associated, or
between CAs, which cross-certify one another. A manage-
ment protocol can be used to carry user or client system
registration information, or requests for certi®cate revoca-
tion. Management protocols that facilitate message format
and transmission are de®ned in Refs. [4,24].
5.4. Certi®cate policies
Certi®cate policy and certi®cate practice statements
should address a variety of protocol security requirements
such as physical and personal security, subject identi®cation
requirements, revocation policy and others. PKI of Ref. [26]
provides such a framework.
5.5. Time-stamp and data certi®cation services
Time-stamping is a service in which a Time-stamp
Authority (TSA), which may be a TTP Ð signs a message
to provide evidence that it existed prior to a speci®c time. A
Time-stamping Protocol [9] provides some support for non-
repudiation so that a user cannot claim that a transaction was
later forged after compromise of a private key. Existence of
the signed time-stamp indicates that the transaction in
question could not have been created after the speci®ed
time.
A token associates a message with a particular event and
provides supplementary evidence for the time speci®ed in
the time-stamp token. For example a token could associate
the message with the most recent ®nal currency exchange
rate for the day.
A Data Certi®cation Server protocol [5] is a TTP that
veri®es the correctness of speci®c data submitted to it thus
going beyond a simple time-stamping service. The DCS
certi®es possession of data or validity of another entity's
signature. As part of this, the DCS veri®es the mathematical
correctness of the actual signature value contained in a
request and also checks the full certi®cation path from the
signing entity to a trusted point (e.g. the DCS's CA, or the
root CA in a hierarchy).
5.6. PKI authorities, services and toolkits
In Australia, Baltimore has been granted full accredita-
tion for `Gatekeeper' Ð the Australian Government PKI Ð
The Government Public Key Authority (GPKA), provides
public key infrastructure services for online Government
services. Other Australian organisations with `entry level'
status include eSign (Verisign and Telstra), Price Water-
house Coopers, 7 while other regional PKI authorities
include: 128i-BayCorp (New Zealand), Singapore Govern-
ment, Hong Kong Post, and others. Suppliers of PKI
systems include: Entrust (PKI 4.0), RSA (Keon 5.0), Micro-
soft (Windows 2000), Baltimore (Unicert), IBM Vault
Registry and SecureWay Trust Authority 3.1.
6. Risks associated with the use of PKI
Security has long been identi®ed as the major obstacle to
Internet-based commerce and PKI is frequently quoted as
the solution critical to secure transmissions over the Inter-
net. More recently questions have been raised [11] and this
reference questions some of the fundamental assumptions of
the PKI solution. The risks outlined in this paper are
discussed here Ð and to a considerable degree refuted. 8
7
www.betrusted.com.
8
Comments drawn from Albertson, A., Analysis on the Ten Risks of
Using PKI, Work in Progress, University of Canterbury, 2000.
 R. Hunt / Computer Communications 24 (2001) 1460±1471
Fig. 4. Sample of certi®cates preloaded in Microsoft Internet explorer.
Can we trust the CAÐ and for what purposes are they
trustworthy?
While it is possible that a `rogue' CA could be set up that
issued certi®cates of dubious value, a customer or business
would still need to be convinced that they are of some value
and can be trusted. Currently browsers contain a number of
public certi®cates from CAs that the user considers to be
trustworthy (see Fig. 4). If a certi®cate from an unknown
CA is presented, the browser informs the user that this
certi®cate is from an unlisted CA and requests con®rmation
before acceptance.
Who has access to your private key and how safe is it on
your computer?
This is the greatest weakness of any cryptographic system
controlling access to private keys and is not speci®cally a
PKI issue. Cryptographically strong private keys are stored
on a computer that is protected by a cryptographically weak
system such as normal passwords. However this is not a
dif®cult problem to guard against. Thus the risks here are
real but they are the same as with any cryptographic system
Ð the weakest link being that of controlling access to the
keys rather than the strength of the encryption algorithm.
How secure is the verifying computer?
The issue here is Ð can an attacker add their own private
key to a list of keys used by the verifying computer? This
would allow an intruder to issue their own certi®cates that
are indistinguishable from legitimate certi®cates. It would
1469
be expected that CAs take adequate measures to provide
such protection and a good security audit would ensure
this to be the case. For example VeriSign's issuing compu-
ters is housed in a secure non-networked environment that
requires multi-operator simultaneous access to counter such
problems.
Can one determine which person is linked to a certi®cate
and how is this person different from any others?
If all that was know about someone was that their name
was John Robinson and then one met someone called John
Robinson, there is not enough information to determine if
this is an exact match. In real life, additional information is
known and this is the very reason why multiple factor
authentication is becoming commonplace.
When a digital certi®cate is received from somebody,
additional information is available over and above the
name. Even if the certi®cate cannot authenticate a person
it does show that the same private key signed every message
received from John Robinson. To assist with such an issue,
public key CAs such as VeriSign offer a certi®cate hierarchy
as was discussed in Section 3.2.1.
Can the CA determine whom they are dealing with? Who
has granted authority for the CA to be an authority?
Private CA organisations that have bought PKI soft-
ware and systems from companies can generate their
own certi®cates. As they know who the people in
their organisation are, they can identify who is being
1470 R. Hunt / Computer Communications 24 (2001) 1460±1471
issued with certi®cates. The major weakness is that
although the private CA can authenticate whom they
have issued certi®cates to, a recipient may not be able
to identify, who the CA is.
Public CAs such as VeriSign have the opposite problem.
Everyone can identify the CA `VeriSign or an international
Af®liate' but who is named on the certi®cate? To overcome
this inherent limitation, again CAs such as VeriSign can
offer a hierarchical level of certi®cates with appropriate
levels of information content and associated trust (See
Section 3.2.1).
Does the user get to see, read or check the certi®cate or is
it processed automatically within the computer? Does the
user control when a certi®cate is sent?
In practise both Netscape Navigator and Microsoft
Internet Explorer ask the user before any certi®cates are
sent (https://digitalid.verisign.com/client/help/privacy.htm)
although most users prefer the automatic features and
allow the process to operate on their behalf. This is not
similar to the manner in which cookies operate Ð most
users do not read, edit or analyse their cookies.
Is the user dealing with the CA or the CA and an RA?
Some systems on-sell the rights to certi®cate production
to other companies. If a company does not consider itself an
authority it can buy the rights to issues certi®cates from an
RA. This is more a theoretical risk since the major issue is
whether the CA will follow the guidelines set down by the
RA. While it is possible that a company could start issuing
certi®cates without following the procedures or proper
authentication checks for its users, it is the responsibility
of the RA to control such subcontracts. As all full CAs have
an RA authority function as well, it is just as likely that a full
CA will not follow the correct procedures as a subcontracted
CA. So overall the risk is low as long as good business
practises are adhered to.
This does raise the issue of new companies entering the
market. Most customers are likely to choose an established
supplier, which has a trusted history. This does mean that
the current dominant public CA (VeriSign and its interna-
tional af®liates), will continue to have a virtual monopoly on
public CA certi®cation.
How secure are the certi®cate practices? Can anyone
steal a certi®cate? Can certi®cates be revoked? Do certi®-
cates have a lifetime?
Again the issue of stolen certi®cates relates to good
business practice, private key security, etc. Certi®cate revo-
cation and lifetime are pertinent management issues, which
can currently be solved with small to medium scale PKI
systems. Both VeriSign and Entrust explain these problems
to their customers on their web sites. VeriSign has greater
control as is responsible for generating certi®cates, which
have a ®nite lifetime (normally one year) as well as a simple
mechanism for users to revoke and renew their certi®cates
(www.verisign.com/repository/digidren.html). The operation
of PKI on a much broader scale does pose some important
issues for the storage of revoked certi®cates and expired
keys. However, the solution to these issues should not
impede the use of PKI at this time.
In summary Ð although there is some element of concern
over the path of trust, it is likely that CAs will become linked to
de®nitive sources such as a Government Department (e.g.
Ministry of Commerce or other Government Security Bureau)
Ð even though the CA as seen from a user's perspective may
well be a (quasi) private organisation. The issuing of passports
by the Government passport of®ce Ð via another Department
or quasi government body Ð is not unlike the manner in which
digital certi®cates could be issued.
7. Summary
This paper has reviewed a range of technical, infrastruc-
tural, operational and management issues associated with
the use of PKI. The major problem lies not in that it has a
number of limitations but that its supporters have sold it as a
super safe security system [12]. They have equated the
cryptographic strength of current asymmetric and
symmetric algorithms with that of the strength of the PKI
system itself. There is no weakness in the cryptographic
strength of the encryption and digital signature processes.
However, the management of these processes, storage of
cryptographically strong keys, identi®cation of entities,
storage of certi®cates, etc. all need be subject to good
business practices Ð common to many security-based
business infrastructures.
PKI is still open to misrepresentation but the improve-
ments mentioned above would go a long way to ensuring
realistic expectations from PKI.
PKI is still in its infancy and yet many organisations have
already begun deploying certi®cate-enabled applications
and infrastructures. 9 Looking ahead, businesses and organi-
sations who intend to use PKI will have to look at issues
such the legal aspects of liability, 10 interoperability between
multiple PKIs, certi®cation validation paths, protection of
private keys and user acceptance.
PKI is a very promising security technology and if used
properly, businesses and organisations can bene®t from it to
support a number of E-business initiatives, ranging from
electronic commerce to secure communications to reduced
infrastructure. The development of smart-cards is also likely
to be closely linked to future PKI development and deploy-
ment. However at this stage Ð given the complexity of the
infrastructure required to implement and support a public
PKI system Ð continued deployment of PKI-enabled
applications for speci®c industry groups seems to be the
most likely path. By addressing the issues described
above, organisations should be able to take full advantage
of this new and signi®cant technology.
9
An example of this is the U.S. Department of Defense (DOD) imple-
menting PKI department wide during the 2000±2003 timeframe.
10
The legal status of digital signatures still requires further clari®cation
[2].
 R. Hunt / Computer Communications 24 (2001) 1460±1471
References
[1] A. Arsenault, S. Turner, Certi®cation Practice Statement, Internet
Draft PKIX Roadmap, October 1999.
[2] R.W. Daniels, The Legal Aspects of PKI ISSA Password, March/
April, 2000, pp. 3ndash;4.
[3] W. Dif®e, M.E. Hellman, New directions in cryptography, IEEE
Transactions on Information Theory 22 (1976) 644±654.
[4] M. Myers, X. Liu, B. Fox, J. Weinstein, ªCerti®cate Management
Messages over CMSº, kdraft-ieft-pkix-cmc-xx.txtl, July 1999.
[5] C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato, ªInternet X.509
Public Key Infrastructure Data Certi®cation Server Protocolsº, kdraft-
ietf-pkix-dcs-xx.txtl, March 2000.
[6] L. Bassham, D. Johnson, W. Polk, ªInternet X.509 Public Key
Infrastructure: Representation of Elliptic Curve Digital Signature
Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public
Key Infrastructure Certi®catesº, kdraft-ietf-pkix-ipki-ecdsa-xx.txtl,
October 1999.
[7] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, ªX.509
Internet Public Key Infrastructure Online Certi®cate Status Protocol
Ð OCSP Extensionsº, September 1999.
[8] S. Santesson, W. Polk, P. Barzin, M. Nystrom, ªInternet X.509 Public
Key Infrastructure Quali®ed Certi®catesº, kdraft-ietf-pkix-qc-xx.txtl,
February 2000.
[9] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, ªInternet X.509 Public
Key Infrastructure Time Stamp Protocolsº, kdraft-ietf-pkix-time-
stamp-xx.txtl, March2000.
[10] Electronic Commerce Promotion Council of Japan (ECOM) Certi®-
cation Authority Working Group, Certi®cation Authority Guidelines,
www.ecom.or.jp, 1997.
[11] C. Ellison, B. Schneier, Ten risks of PKI: what you're not being told
about public key infrastructure, Computer Security Journal 16 (1)
(2000) 1±8.
[12] The Security Enabled E-business (White paper) (www.entrust.com),
1999.
[13] A Total Economic Impact Analysis of Two PKI Vendors: Entrust and
Versign, White Paper, Giga Information Group (www.entrust.com),
1998, pp. 1±24.
[14] PGP attacks, http://axion.physics.ubc.ca/pgp-attack.html, 1999.
[15] N. McBurnett, PGP Web of Trust Statistics.1999 kget rest of
referencel.
[16] RSA Laboratories, The Public-Key Cryptography Standards (PKCS),
RSA Data Security, Redwood City, California, November 1993.
[17] D.W. Chadwick, ªInternet X.509 Public Key Infrastructure Opera-
tional Protocols Ð LDAPv3º, August 1999.
[18] A. Arsenauly, S. Turner, ªInternet X.509 Public Key Infrastructure
PKIX Roadmapº. kdraft-ietf-pkix-roadmap-0x.txtl, March 2000.
[19] J. Reavis, Is VPN the Killer Application for PKI?, www.nwfusion.-
com/newsletters/sec/0920sec2.html, 1999.
1471
[20] M. Wahl, T. Howes, S. Kille, ªLightweight Directory Access Protocol
(v3) º December 1997.
[21] R. Atkinson, 1998. Security Architecture for the Internet Protocol.
RFC 2401, 1998. RFC 2402 and 2406 are also related.
[22] D. Harkins, D. Carrel, Internet Key Exchange (IKE), 1998 and kdraft-
ietf-ipsec-ike-01.txtl, 1999
[23] R. Housley, W. Ford, W. Polk, D. Solo, ªInternet X.509 Public Key
Infrastructure Certi®cate and CRL Pro®leº, January 1999.
[24] C. Adams, S. Farrell, ªInternet X.509 Public Key Infrastructure Certi-
®cate Management Protocolsº, March 1999.
[25] M. Myers, C. Adams, D. Solo, D. Kemp, ªInternet X.509 Certi®cate
Request Message Formatº, March 1999.
[26] S. Chokhani, W. Ford, ªInternet X.509 Public Key Infrastructure
Certi®cate Policy and Certi®cation Practices Frameworkº, March
1999.
[27] R. Housley, W. Polk, ªInternet X.509 Public Key Infrastructure
Representation of Key Exchange Algorithm (KEA) Keys in Internet
X.509 Public Key Infrastructure Certi®catesº, March 1999.
[28] S. Boeyen, T. Howes, P. Richard, ªInternet X.509 Public Key Infra-
structure Operational Protocols Ð LDAPv2º, April 1999.
[29] A. Arsenauly, S. Turner, ªX.509 Internet Public Key Infrastructure
Online Certi®cate Status Protocol Ð OCSPº, 2000.
[30] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, ªX.509
Internet Public Key Infrastructure Online Certi®cate Status Protocol
Ð OCSPº, June 1999.
[31] R. Housley, P. Hoffman, ªInternet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTPº, July1998.
[32] S. Boeyen, T. Howes, P. Richard, ªInternet X.509 Public Key Infra-
structure LDAPv2 Schemaº, June 1999.
[33] C. Ellison, ªSPKI Requirementsº, September 1999.
[34] C. Ellison et al., SPKI Certi®cate Theory, September 1999.
[35] R. Rivest, A. Shamir, L. Adleman, A method for obtaining digital
signatures and public key cryptosystems, Communications of the
ACM 21 (1978) 120±126.
[36] RSA Data Security, ªUnderstanding PKIº. (www.rsa.com) 1999.
[37] S. Taylor, Choosing a PKI Vendor Ð Total Cost of Management
Analysis of Entrust, VeriSign, and Equifax; White Paper (www.equi-
fax.com/) 2000, pp. 1±15.
[38] Public Key Infrastructure Ð The VerisSign Difference; White paper
on VeriSign web site (www.verisign.com/whitepaper/enterprise/
difference), 1999.
[39] VeriSign Certi®cation Practice Statement, www.verisign.com/reposi-
tory/CPS1.2/intro.html, 1997.
[40] VeriSign., VeriSign Certi®cation Infrastructure, 1997,https://
www.verisign.com/repository/CPS1.2/CPSCH2.HTM#
toc361806948.
[41] P. Zimmermann, www.pgp.com, 2000.