Authentication on the Edge of the Network

A Critical Review of X.509 PKI

Andres Nieto, Rinaldo DiGiorgio, Chris Nwosisi, and Richard Washington

DCS823
DPS Program in Computer Science
Pace University
April 7, 2006
Abstract

Many of the common technologies in use today by millions of users are routinely
compromised at the consumer, the private enterprise, and the government level. Systemic
solutions are required to protect consumers, and secure private and public organizations
from threats like identify theft, theft of corporate data, fraudulent transactions, etc. X.509
PKI, proponents claim, is the technology that would deliver the secure authentication and
access controls necessary for e-commerce, secure e-mail, and a plethora of other
environments and applications. We present is this paper an X.509 PKI (brief) history, the
canonical architecture, the deployment experience, and (some) of the problems of X.509
style PKIs. We conclude on the basis of the X.509 PKI shortcomings that this technology
will fail to deliver on its promise.

Key Words

Authentication, access control, trust, identity, key, PKI, directory, certificate, CA, X.509,
RA, revocation, CRL, OCSP.

1. Introduction

X.509 PKI is general purpose, very flexible, highly complex, and expensive public key
infrastructure. Originally conceived as an access control technology for X.500
directories, it has evolved into an authentication and access control technology for a wide
range of applications and environments while retaining (most) of its architectural
heritage. Today’s applications and environments are been forced to “fit” the model of
X.509 PKI which seems unable to meet their security demands.

Without certificates, we are told, customers will not trust a site, site’s will not be secured,
and business transactions must not take place. Without certificates, we are told, it will be
difficult or close to impossible to secure communications or to electronically sign
documents. Certificates are widely deployed still identity theft, data theft, electronic
transaction fraud, phishing, etc., have become common occurrence. X.509 PKI seems
unable to prevent and contain the attacks.

Academics and practitioners have proposed solutions covering the spectrum: from doing
away with X.509 PKI altogether like ANSI X.959, to supplementing X.509 PKI with
technologies like smart cards, to those that simply ask for more of the same good thing
like PKI4IPSEC.

The remainder of this paper is organized as follows. Section 2 presents some security
definitions. Section 3 reviews the history of X.509 PKI. Section 4 presents the rationale
for certificates. Section 5 describes a canonical architecture of X.509 PKI. Sections 6, 7,
8 and 9 cover X.509v3 certificates. Section 10 covers the technology adoption
experience. Section 11 presents a sample interaction. Section 12 covers X.509 PKI
problems. Section 13 offers our conclusions, alternatives, and our expectations about
research and market forces regarding X.509 PKI.

2
2. Computer Security – Some Basic Definitions [16]

A security policy identifies the threats and states the requirements for a secure system.
System security services protect against the threats to the system. The security services
implement security mechanisms that protect, detect, and recover from attacks.

The basic system security services are: confidentiality, integrity, and availability.

Confidentiality is the concealment of information or resources. Access control

mechanisms support confidentiality. Access control mechanisms can prevent illicit access
to information or resources; conceal the existence of information or resources; and
scramble the information.

Integrity refers to the correctness and trustworthiness of information or resources; the

prevention of improper or unauthorized change. Integrity includes data integrity, origin
integrity (also called authentication), and non-repudiation.

Availability is the ability to access information or a resource when need it; its readiness
for usage. Availability is an important concern of system designers and its security
aspects have to do with preventing, detecting, and recovering from deliberate attempts to
block access to information or a resource (also called denial of services attacks).

A threat is a potential violation of security; its realization is called an attack. Threats can
be canonically divided in four groups: disclosure (unauthorized access to information or
resources), deception (acceptance of false information), disruption (interruption of correct
operation), and usurpation (unauthorized control of parts of the system).

The basic security services of confidentiality, integrity, and availability are sufficient to
deal with the threats of disclosure, deception, disruption, and usurpation.

A security policy partitions a system in a set of secure and nonsecure states. In terms of
security policies, confidentiality states whether information or a resource can be disclosed
and to whom. In terms of security policies, integrity states to what a degree information
or a resource can be trusted.

A system is trustworthy if there is sufficient, credible evidence the system meets its
security requirements. Assurance techniques measure a system’s trustworthiness. Trust
and assurance play a fundamental role in computer security since security policies rest on
fundamental assumptions about the policies, the system, its environment, and its
operation.

There are different access control mechanisms: identity-based, rule-based, originator-

controlled, history-based, capability-based, etc. In identity-based access control
mechanisms the identity of the entity (trying to access the information or the resource) is
the key. Identity-based access control can be implemented via access control list (tied to
the information or resource) or capabilities (tie to the entity).

3
Systems assign an identity to each external and internal entity (also known as subject or
principal) that needs to be uniquely identified.

Authentication is the proving or verification of information. Authentication binds an

identity to an entity. The entity presents credentials that enable the system (or another
entity) to confirm the entity’s identity (also known as identification). Credential can take
many forms: what the entity knows, what the entity has, what the entity is, where the
entity is, and any combinations of these.

Cryptosystems can be used to provide confidentiality and integrity services. Classical

cryptosystems use the same key for encipherment and decipherment. This shared key
needs to be communicated to the parties via a secure channel. When communicating a
message the transmitting and receiving parties share the same key. Public key
cryptosystems use two keys: one private and the other publicly known. When
communicating a message the transmitting party enciphers the message with the
receiving party public key. The receiving party deciphers the message with its private
key. With public key cryptosystems the communicating parties no longer need a secure
channel to communicate a shared key.

Cryptographic key infrastructures provided the necessary additional services and

mechanisms needed to use cryptosystems securely. Cryptographic key infrastructures
address issues like key management, key exchange and authentication, etc.

Key management involves the binding of an identity to a key; and the generation,
distribution, maintenance, and revoking of cryptographic keys.

3. Public Key Infrastructures – A Bit of History

Diffie and Hellman [31] when introducing the concept of public key cryptography
suggested a solution to public key distribution: the enciphering key was to be made
public by placing it in a public directory (which they called the public file) along with the
user’s name and address. The presence (in the public file) of the name, key pair implied
that it was a valid name, key pair. In today’s terminology the public file would be called a
Trusted Directory. The concept of a public file had inherent flaws including being a
performance bottleneck, the complexity of such large system, the need to control access
(to prevent unauthorized modification), the potential for denial of service, the potential
for usurpation, the need to support off-line operation, the problem of name management
(a problem more difficult than the one of key management), etc.

Kohnfelder [63] in his bachelor’s MIT thesis argued in favor of the public file noting that
when direct, reliable exchange of the parties’ keys is not possible the next best alternative
is to trust a third party: the public file. Realizing the inherent flaws of the public file,
Kohnfelder introduced the concept of certificates. Certificates can only be created by the
public file. In today’s terminology the public file would then be called a Certificate
Authority. Certificates bind a name to a key and are signed by the public file. There is a
certificate for each party; each party can check the certificate was created by the public

4
file, and each party conveys its key information by sending its own certificate.
Kohnfelder resolved many of the problems of the public file with the creation of
certificates and by separating the signing and lookup operations. Still many problems
with the public file remain unresolved and new ones were introduced as a result of its
(new) role of certificate authority.

In the mid-1908s the ITU and ISO began independently to work on directory services
[58]. ITU wanted a global white pages directory to look up telephone numbers and
electronic mail addresses. ISO wanted a directory to serve as a name service for OSI
networks. The two efforts merged and in late 1988 the X.500 standard was approved.
X.500 specifies a global search repository of (hierarchically) named authorities and
(hierarchically) named entities. A path through the directory is defined by a series of
relative distinguished name (RDN) components that together form a (unique)
distinguished name (DN). The X.500 single root hierarchy have the potential to assign a
globally, unique name to every possible object. A variety of access control mechanisms
were prescribed including passwords, hashed passwords, and digital signatures. Each
portion of the directory had a CA attached to it that issue X.509v1 certificates (a root CA
at the root, national CAs at the country level, etc.); that issue X.509v1 certificates [3].
X.509v1 certificates tied a public key to a node and bound a distinguished name to a key.
Since the distinguished name took the place of an entity’s name the certificate was called
an “identity certificate”.

By 1983 the IETF begins the deployment of DNS: a global lookup repository of
(hierarchically) named authorities and (hierarchically) named entities. The DNS has a
single root hierarchy [74].

In 1993 the X.509 was revised producing version 2 of the standard. This version of the
standard resolved outstanding issues having to do with the details of a X.509 certificate,
certification authorities, etc. Late 1993 and early 1994 saw the first implementations of
X.509 PKIs.

In 1993 the IETF proposed Private Enhance Mail (PEM) based on the X.509v1
certificates [12, 61, 65].

In 1996 the X.509 was revised producing version 3 of the standard. X.509v3 certificates
support extensions. Extension field types may be specified in standards or defined and
registered by any organization (to be included in its certificates). Some common
extensions include KeyUsage which limits the use of the key for a particular purpose and
AlternativeNames which allows for identifiers (other than DNs) to be identified with the
public keys. These implementations of X.509v3 certificates are also known as Attribute
Certificates.

In the fall of 1995 the IETF began work on PKIX (Public Key Infrastructure X.509) with
the intent of developing Internet standards necessary to support an X.509 PKI [6, 7, 9, 10,
13, 14, 17, 24, 29, 42, 50].

Alternatives to X.509 PKI have been proposed/developed over the last 10 years
including: SPKI (Simple PKI) [33, 35], AADS (Account Authority Digital Signature) [4,

5
5, 62], PGP (Pretty Group Privacy) [3, 84], etc. Some of the alternatives represent
paradigm shifts from the concept of X.509 PKI [4, 90].

4. Certificates – Rational

Certificates were originally conceived as tokens that bind an identity to a (public)

cryptographic key. The parties convey key information to one another by simply sending
their certificates. The parties can easily read the certificate (name to key information
binding) and verify the certificate (by authenticating the CA digital signature).

A new party has to communicate with the CA once before is able to communicate with
other parties within the system. Each new party presents to the CA name, credentials, and
encryption information. The CA performs the necessary information authentication, binds
a name to a key through a digital signature (computing the certificate), and stores the
certificate in a repository. The new party is given its certificate and the CA public key.

The repository doesn’t need to be trusted, it can be replicated, it can be hardened, it can
be made highly available, off-line operation is possible, etc [49, 53].

Certificates and their associated cryptographic infrastructure seemed to resolve public

key cryptosystems problems of authentication and key distribution [63, 1].

5. X.509 PKI – Infrastructure

The (canonical) infrastructure of a X.509 PKI [82] includes : an authority responsible for
the creation or aiding in the creation of certificates, a certificate issuance process, a
certificate termination process, (trust) anchor management, (private) key management,
and a certificate validation process.

A CA issues X.509 certificates that bind the distinguished name to the public key. The
structure of CAs is hierarchical. There are three types of certification authorities
(according to X.509v1):
1. A Policy Registration Authority (PRA) which is the root of the certification hierarchy
at the first level. This authority issues only certificates for the next level of authorities
(PCAs). According to X.509v1 all the certification chains start with this root
authority.
2. Policy Certification Authorities (PCA). They are at the second level of the hierarchy
and each PCA is certified by the PRA. A PCA creates and publish a statement of its
policy with respect to certifying users or certification authorities: A Certificate
Practice Statement. Distinct PCAs aim to satisfy different needs of different users.
3. Certification Authorities (CA). CAs are at the third level of the certification hierarchy
and can also be at lower levels. Those at level 3 are certified by PCA. Certification
authorities usually represent particular organizations or their units. Trust associated
with a certification chain is implied by the PCA name. The name rule ensures that
CAs below one PCA are constrained to a limited set of entities they can certify (e.g. a
CA for an organization can only certify entities in that organization’s name tree).

6
An RA (Registration Authority) is an optional entity responsible for accepting request for
certificates on behalf of a CA. Its tasks include confirming the subject’s identity,
validating that the subject is entitled to have the values requested in a certificate,
verifying the subject has possession of the private key associated with the public key
requested in the certificate.

Certificates contain expiry dates that provide for default termination. Certificates can also
be revoked and the revocation must be communicated by posting the revocation in a
Certificate Revocation List (CRL) or made available on-line via an Online Certificate
Status Protocol (OCSP) server. The “location” of the CRL is included with the certificate.

CA certificates are needed to verify other certificate. All certificates that maybe trusted
by the client are issued directly or indirectly (within the hierarchy) by a trusted CA, or a
third-party may hold the public key of (a trusted) CA that issue its certificate. There are
several mechanisms provided by the standard to retrieve (trust) anchors as part of the
registration and key management processes. Additionally, the software application (i.e., a
Web Browser) may include Certificate Trust List (a list of various trusted CAs) or it may
query its CA for a list of trusted certificates.

The standards support key management protocols (of the CA and clients). The
functionality supported varies between the different implementations. In general,
certificates can be rekey or renew (subject to CA policies). A rekey generates a new key
pair to replace the expiring key pair. A renewal creates a new certificate for the existing
key pair.

Clients use their trust anchors to verify certificates and to build certificate signature
chains. Trust in certificates issued by other CAs can be obtained through cross-
certification between the CAs or by importing or retrieving the certificates of other CAs
as needed. There are many other possibilities. Regardless, the client is supposed to
retrieve and verify the entire chain of certificates.

6. X.509 Certificates – (Main) Attributes

X.509v3 is the current version of the X.509 standard. A description of its main attributes
follows [16, 54] :

1. Version. Each new version of X.509 certificates has had new fields added.
2. Serial Number. Unique for each certificates issue by the CA.
3. Signature Algorithm Identifier. Identifies the algorithm, and any parameters, used to
sign the certificate.
4. Issuer’s Distinguished Name. CAs need to use proper DNs.
5. Validity Interval. Times at which the certificate becomes valid and expires.
6. Subject’s Distinguished Name. Name that uniquely identifies the subject to whom the
certificate is issued.
7. Subject’s public key information.
8. Issuer’s Unique Identifier. Allows for the reuse of a CAs name over time.

7
9. Subject’s Unique Identifier. Allows for the reuse of a subject’s name over time.
10. Extensions. X.509v3 defines certain extensions concerning key and policy
information, certification path constraints, CA, and subject information. A constrain
may for instance limit key usage to digital signatures, limit the DNs for which a CA
may issue certificates, etc.
11. Signature. Identifies the algorithm, and any parameters, used to sign the certificate,
followed by the signature

To verify a certificate issued by a trusted CA, the party obtains the CA’s public key for
the particular signature algorithm (field 3), and deciphers the signature (field 11). The
party proceeds to use the information in the signature field to recompute the hash value
from the other fields. Signature chains are used to verify a certificate signed by an
untrusted CA.

7. X.509v3 Certificates - Profiles

The X.509v3 standard doesn't set limitations on combinations of what can and can't
appear in the different certificate types [16, 54]. More specifically, there are a number of
options with respect to the fields and extensions that a CA may include in the certificates
it issues. Profiles have emerged to specify the content to include in particular applications
and operating environments. Depending on the environment in which a CA operates, and
the entity a certificate is issued to, the content of certificates differ. Also trust constraints
may limit the potential set of candidate certificates.

The major profiles in use today include PKIX (The Internet PKI profile), FPKI (US
government PKI profile), MISSI (US DoD PKI profile), ISO 15782 (Banking Certificate
Management Part 1: Public Key Certificates), TeleTrust/MailTrusT (German MailTrusT
profile for TeleTrusT), German SigG Profile (profile to implement the German digital
signature law), ANX Profile (Automotive Network Exchange profile), Microsoft Profile
(this isn't a real profile, is the Microsoft way).

Applications have to conform to certificate profile processing rules. Some profiles dictate
(at least) some DN components to be present, the degree of support of constraint for
constraint extensions varies, the interpretation of the meaning of many fields (KeyUsage,
digitalSignature, NonRepudiation, etc,) varies, some CAs use policy qualifiers (for the
certificatePolicy and policyContraints extensions) in their certificates, etc.

8. X.509v3 Certificate Classes - Binding

Ellison states that there are three classes of information that can be bound by a public key
certificate [12, 75]: key, name, and authorization (or any other attribute). The binding
may be indirect: a reference to another certificate.

Thus there are three general classes of certificates, mapping two of the three classes of
information: Identity Certificates that map a name to a key, Attribute certificates that map
an authorization to a key, Attribute Certificates that map an Authorization to a name.

8
Attribute Certificate give rise to additional cryptographic infrastructures including an
Attribute Authority (that could be different than the CA), an Attribute Verifier (that could
be different than the RA), and an Attribute Certificate Repository.

X.509 PKI as originally conceived is an authentication technology.

9. X.509v3 Certificate Classes – Level of Trust

CAs also offer different classes of certificates depending on the level of trust desired. A
“low” level of trust certificate may imply little or no assurance by the CA of the
requester’s credentials; a “middle” level of trust certificate may imply a reasonable but no
fool proof attempt by the CA of authenticating the requester’s credentials, a “high” level
of trust certificate may imply an in-person application, public notary certification of
documentation authenticity, proof of incorporation (for businesses), etc.; [11, 24, 38, 45,
92, 93].

10. X.509 PKI – Adoption Experience

X.509 PKI is broadly used (mostly) for SSL server-side authentication. Numerous
applications and operating systems support it (UNIX, Windows, Cisco IOS, CheckPoint,
multiple e-mail clients and servers, etc.). Some applications and environments are being
retrofitted to support PKI (i.e.; IPSec). New PKI services and protocols are been
proposed (i.e.; RFC4387 of February 2006 codifies the use of HTTP/HTTPS to access
certificates and CRLs from PKI repositories). Many governments and private institutions
are adopting PKI.

Yet X.509 PKI was expected to be widely adopted for e-commerce, banking, for user
authentication and authorization (passports, driver’s license), etc.; but it seems to have
failed to capture those markets. The reports from large scale X.509 PKI implementations
indicate that X.509 PKI implementations can be costly, difficult, of low quality, with low
availability, and poor-performing.

As of February 2004 only SkandianBanken of Norway was reported to be using X.509

certificates to enroll customers. A review by student(s) from University of Bergen found
SkandianBanken PKI implementation easy prey to multiple attacks [90].

The US GAO reported on 2001 [43] “…Despite recent progress, designing and
implementing systems fully able to utilize PKI technology within the government
remains a serious challenge…” It went on to mention as main obstacles: (lack of)
interoperability between the different PKI products available on the market, operational
experience (not full-featured PKIs have been implemented yet), affordability (the high
cost associated with deploying PKI, high cost of operation, high cost associated with
retrofitting applications to use it, etc.), (lack) of well defined and enforced policies and
procedures, etc.

9
Mike Pearson on a 2003 New Zealand e-government conference [79] reported on the
international experience with PKI and found PKI complicated and expensive, flawed
business cases, high associated cost, low citizen uptake, etc. He reported on how
withdrawals of commercial CA services threaten PKI projects, and on the poor
availability, quality, and performance of CA services. He went to recommend small pilot
projects, control of the environment (no MS updates), to hide PKI from the user, etc.

Still X.509 PKI vendors and advocates continue to tout its advantages and suggest that
more uses be found for the technology [77]

11. X.509v3 PKI – Sample Interaction

Alice wishes to communicate securely with Bob, she doesn’t yet have her own keys or
certificate to use in the communication. Alice first generates a public/private key pair
using a public key algorithm like RSA. She contacts the RA and submits her certificate
request. The request contains Alice unique name, her credentials, and her public key.
After authenticating Alice credentials and approving the issue of the certificate, the RA
forwards the request to the CA for policy approval and signing. The RA delivers the
certificate to Alice and the CA’s public key. Alice now has a valid certificate.

Alice proceeds to contact Bob. Alice must get Bob certificate and verify it. Bob must get
Alice’s certificate, and verify it. They also must decide in the security services and
mechanisms they will use to ensure the confidentiality and authenticity of their
communications.

Consider Bob, if Bob and Alice are both on the same CA, then it is easy for Bob to verify
Alice’s certificate. If Bob and Alice have different CAs, then Bob must ask his CA to
find a trusted path to Alice’s CA. The trusted path must be such that for each CA the CA
acting as a client already has the serving CA’s public key, with which the client may
verify the server’s signatures.

Once Alice and Bob verify their certificates and agreed to the security services and
mechanisms for their ensuing communication then they can proceed to send messages to
one another. For instance, Alice could encrypt messages to Bob with Bob’s public key
and sign them with her private key. Bob will decrypt these messages with his private key,
decrypt Alice’s signature with Alice’s public key and verify the messages authenticity.

12. X.509 PKI – Issues

Names as Global Unique Identifiers

Names can’t be use as global unique identifiers . (Individual) certificates deployed with
people’s birth names don’t scale.

Ellison [32] as way of example showed that if names were assigned by some central
authority to 6 billion people, names would need about 32.5 bits of entropy. If English

10
spelling was used at 1.5 bits of entropy per character, that calls for names of 50 characters
in length. However, parents don’t choose names randomly. Since name choices are not
(statistically) independent the consequent reduction in entropy calls for even longer
names.

DNs

X.500/X.400/X.509 DN includes a field called the Common Name (CN). The name
people use in daily life. This is a normal name like “John Doe”.

Even if there were X.500 directories with a single naming root, the DN would not be a
name suitable for global use. The common name isn’t a valid identifier.

Some applications like Microsoft Outlook/Exchange use DNs, even though there is no
single naming root. However, to be friendly to the user they only present the CN portion
of the DN – the user-friendly portion. These applications will work well only in small
deployment scenarios. The corporate environment is full of anecdotes about e-mail
naming/sending confusion. Worst off a digitally signed message still only shows the CN.
Security decisions based on CNs can have disastrous consequences.

Creating DNs

Most IT personnel aren’t versed in X.500 and its DN conventions. Furthermore, global
attempts to formalize the naming scheme failed. Therefore, most directory administrators
have to contend with determining in their application and operating environments what
constitutes the Country (C), the State or Province (SP), the Locality (L), the organization
(O), the organizational unit (OU), the administrative domain (D), etc.; [51, 53]. Even if
they determine these, it is still possible to assign to an object multiple and unique DNs;
just as it is possible not to assign all the (necessary) components of the DN (and
applications differ regarding what components of a DN deem required).

Different X.509v3 profiles have different rules to process DNs: the German profiles
require C and CN; other profiles allow for null DNs and the use of alternative names
[54].

The confusion around DNs have let people (and CAs) to put just about anything in a DN,
and to the use of alternative names (unique within the application or operating
environment) like e-mail addresses, tax-ids, DNS names, etc.

Disambiguating DNs

It is possible for individuals to have the same DN. To disambiguate names,

administrators (and CAs) have resorted to adding some unique value to the CN like the
last digits of SSN. These ad-hoc solutions create unique names but make name lookups
impossible.

The Directory

11
X.509 PKI relied implicitly on a global X.500 directory that was never realized [3]. There
is no global certificate repository or global CRL or OCSP servers. The certificate
distribution problem was resolved by including every certificate needed wherever it may
be needed (ala CTLs, via caching of verified certificates, etc). The problem of certificate
distribution became a problem of certificate revocation.

Even within a given application and operating environment where directory lookups are
possible, DNs don’t translate to the more familiar Internet naming conventions and don’t
provide for easy disambiguation making directories useless for lookups by third-parties.

ID Certificates

The model of X.509 PKI was one of an ID certificate that would bind an entity to an
entry in the X.500 directory. The assumption was one needed only one such entry.
However, we all have multiple identities (at work, at home, telephone company, ISP,
banks, school, etc.). It isn’t possible to have one ID certificate that lists for an entity all
possible IDs. More over, it doesn’t exist a CA with the authority and (enjoying) the trust
to establish all those IDs to key bindings. Entities are likely to need as many certificates
as they have relationships [32].

ID certificates are also compromised by application and operating environments

practices: many commercial web sites use SSL to secure the client browser/web server
interaction yet many outsource the transaction and (transparently) redirect the client
browser to (third party) web sites without the “necessary” client browser/(third party)
web server authentication [30].

ID certificates may not be needed or be desirable for many applications and operating
environments.

ID Certificates and Authorization

X.509 PKI is (as originally conceived) an authentication technology. Authorization is a

separate issue that may or may not be linked to authentication. This fact alone will seem
to make X.509 PKI unsuitable for most e-commerce environments and applications yet
CAs role(s) continue to expand. CAs today issue bona fide business certificates, code
signing certificates, SSL certificates, etc.

Microsoft IE 6.0 can process certificates with the following purposes: server
authentication, client authentication, code signing, secure e-mail, time stamping,
Microsoft Trust List signing, Microsoft Time Stamping, IP security end system, IP
security tunnel termination, IP security user, Encryption File System, Windows Hardware
Driver Verification, Windows System Component Verification, Embedded Windows
Component Verification, OEM Windows System Component Verification, Embedded
Windows System Component Verification, Key Pack Licenses, License Server
Verification, Smart Card Logon, Digital Rights, Qualified Subordination, Key Recovery,
Document Signing, IP Security IKE Intermediate, etc.

Credentials Authentication

12
CAs have heavily invested on the security of their key and certificate computing process
[40, 41], . They have built large vault with multiple layers of security: cameras, multiple
doors, biometrics, proximity detectors, employees working in the vault are closely
screened, etc. On the basis of the process and its security mechanism CAs argue their
certificates were computed in a secure fashion. However, the greater risk isn’t with the
key/certification generation process but with the processes used to authenticate a
certificate requestor.

Most credential used by CAs for their highest security level certificate can be easily
obtained by fraudulent means. Microsoft reported on Security Bulletin MS01-017 [70]
that “…On January 29 and 30 of 2001 Verisign issue two Class 3 code-signing digital
certificates to an individual who fraudulently claimed to be a Microsoft employee…”

Certificate Lifetime

Certificates have no official mandated lifetime; their life spans are at the discretion of the
CAs and the holder.

A sample certificates taken from Microsoft Internet Explorer V6.0 illustrates the
problem: Viacode Certification Authority, Serial Number 36 e7 ad 9c, valid from
Thursday, March 11, 1999 to Monday, March 11, 2019; VeriSign Class 1 Public Primary
CA, Serial Number 00 cd ba 7f 56 f0 df e4 bc 54 fe 22 ac b3 72 aa 55, valid from
Sunday, January 28, 1996 to Tuesday, August 01, 2028.

Fono and Feinbloom [40] offer as a way of example of the potential for fraud the
following scenario: “…COMPANY.COM holds a Class 3 certificate and its business is
concert promotion. Their domain name, COMPANY.COM is valid for two years and
expires in 2004. They hold a Class 3 certificate that expires in 2010. In 2003,
COMPANY.COM files for bankruptcy and goes out of business. In 2004, Joe Badguy
picks up COMPANY.COM as an available domain name and builds an e-bank site
around it. However, the COMPANY.COM Class 3 certificate is still considered a valid
Identity in the PKI database, and unless Joe calls the PKI vendor to update their records,
he’s inherited six years of the original COMPANY.COM Digital Identity (and associated
trust relationships) without having to do anything! If Joe calls the PKI vendor, he can
probably social engineer an update to the original COMPANY.COM Identity to reflect
his new contact information…thus, when the original COMPANY.COM Identity comes
up for renewal in 2010, he’ll continue to inherit the rights and trusts associated with the
original COMPANY.COM…”

Certificate Revocation List

Revocation requests need to be authenticated and have to be timely disseminated

throughout the infrastructure. CRLs contain the serial numbers of the revoked
certificates, the date on which they were revoked, the name of the issuer, the date on
which the list was issued, when the next list is expected to be posted. The issuer also
signs the list.

13
CRLs don’t work (even if the CRL processes and practices of every CA and applications
and operating environments were perfect). They violated proven principles of data driven
programming (once a datum is out, it can’t never be retrieved), transaction processing
(the CRL can be checked so the transaction remains ACID), and invalidate non-
repudiation (CRLs are often published with retroactive invalid dates).

CRLs aren’t issued frequently enough, are expensive to distribute, and easily susceptible
to DOS.

On January 9, 2004 VeriSign reported [94] “…At midnight GMT (4pm PST) on January
7, 2004, VeriSign experienced a sudden and dramatic increase in the number of requests
by Windows-based clients to download a CRL from crl.verisign.com. The CRL is a file
that confirms the validity status of a set of certificates, and is used by applications and
users to determine whether a particular certificate has been revoked. VeriSign normally
handles 500-1000 connection requests per second at crl.verisign.com, representing 200 -
400 Mbps of traffic. On January 7, 2004, traffic levels increased to 50,000 – 100,000
connection requests/s, representing over 1.5Gbps of traffic. As a result, certain users
attempting to retrieve CRLs experienced intermittent delays. VeriSign immediately took
steps to increase capacity and determine the root cause. Within 24 hours, VeriSign had
increased its capacity on crl.verisign.com ten-fold to handle this increased request
load…”

Microsoft reported on Security Bulletin MS01-017 [70] that “…On January 29 and 30 of
2001 VeriSign issue two Class 3 code-signing digital certificates to an individual who
fraudulently claimed to be a Microsoft employee…VeriSign has revoked the certificates,
and they are listed in VeriSign current Certificate Revocation List (CRL). However,
because VeriSign code-signing certificates do not specify a CRL Distribution Point
(CDP), it is not possible for any browser's CRL-checking mechanism to locate and use
the VeriSign CRL. Microsoft has developed an update that rectifies this problem. The
update package includes a CRL containing the two certificates, and an installable
revocation handler that consults the CRL on the local machine, rather than attempting to
use the CDP mechanism.”

There are many other problems with CRLs including: CRLs can be too long (it is meant
to contain every revocation ever published), all CRL entries need to be parsed in order to
determine if one certificate is valid, CRLs can contain retroactive invalid dates, a CA
revoking its public key has to sign its CRL with a new private key (and it has to
disseminate the new public key), CRLs from different CAs within a signature chain need
to be checked, applications are allowed to cache CRLs, CRL don’t allow for real-time,
on-line updates (and there are applications and operating environments where timely
dissemination of CRL revocation is critical), etc.

VeriSign states in its DOD IECA CPS section 2.6.2 Frequency of Publication [92] that
“…A CRL will be created and published on a daily basis…”

CAs deny or limit liabilities that may rise from the use of their CRL. VeriSign CRL
usage agreement states [96]: “…7. DISCLAIMER. PARAGRAPH 11.3 OF THE CPS
SETS FORTH A LIMITED WARRANTY. EXCEPT AS EXPRESSLY PROVIDED IN

14
PARAGRAPH 11.3 OF THE CPS, ISSUING AUTHORITIES AND VERISIGN
DISCLAIM ALL WARRANTIES AND OBLIGATIONS OF EVERY TYPE,
INCLUDING ANY WARRANTY OF MERCHANTABILITY, ANY WARRANTY OF
FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTY OF THE
ACCURACY OF THE INFORMATION PROVIDED, AND FURTHER DISCLAIM
ANY AND ALL LIABILITY FOR NEGLIGENCE OR LACK OF REASONABLE
CARE…”

VeriSign liability caps are for Class 1 certificates is US $ 100.00, for Class 2 certificates
is US $ 5,000.00, and for a Class 3 certificate is US $ 100,000.00.

Online Certificate Status Checking

The Online Certificate Status Protocol (OCSP) protocol (RFC2560) and its associated
infrastructures (Online Revocation Authorities, OCSP servers, etc.) allow for online
certificate status checking.

A quote from RFC2560 [6] illuminates the problems (the underline is ours): “…This
specification defines the following definitive response indicators for use in the certificate
status value:
-- good
-- revoked
-- unknown
The "good" state indicates a positive response to the status inquiry. At a minimum, this
positive response indicates that the certificate is not revoked, but does not necessarily
mean that the certificate was ever issued or that the time at which the response was
produced is within the certificate's validity interval. Response extensions may be used to
convey additional information on assertions made by the responder regarding the status
of the certificate such as positive statement about issuance, validity, etc.

The "revoked" state indicates that the certificate has been revoked (either permanently or
temporarily (on hold)).

The "unknown" state indicates that the responder doesn't know about the certificate being
requested…”

Compare OSCP range and uncertainties of its status replies with a merchant request for
approval from a credit card company: authorize or decline.

CAs the User Trust

(Public) CAs are businesses that aren’t subjected to regulatory control by governmental
organizations.

Users need evidence of a CA’s trustworthiness. Users requesting and verifying

certificates would need to review a CA’s CP, CPS, CRL Usage Agreement, and other
legal and contractual documents; users would need as well to review other CA policies
like confidentiality policies, dispute resolution, etc.; users would also need to review a

15
CA’s technology, practices, DR, etc.; users would also need to review the CA’s cross-
certification agreements; etc.

The user’s decision to trust a CA is misplaced: no assurance is performed to determine

the level of trust to place on a CA, and the CAs provide little evidence that would lead a
user to determine such level of trust. The risks remain with the user (even without given
any consideration to CAs denial or limited liability).

VeriSign states in its ECA CPS section 1.3.4.2 Relying Parties [93] that “…A Relying
Party is the entity who, by using another’s certificate to verify the integrity of a digitally
signed message, to identify the creator of a message, or to establish confidential
communications with the holder of the certificate relies on the validity of the certificate
that binds the Subscriber’s name to a public key. A Relying Party may use information in
the certificate (such as certificate policy identifiers) to determine the suitability of the
certificate for a particular use and does so at their own risk…”

CAs the Application Trust

SSL-capable browsers come pre-configured to trust “well known” CAs (the CTL). The
users are completely removed from the decision of determining who trust.

The CTL of Microsoft Internet Explorer V6.0 includes well over a hundred trusted root
CAs.

The procedures by which a CA is added by a Browser vendor to its CTL vary: (old)
Netscape just wanted to be paid, Microsoft doesn’t charge but asks for a SAS70, or one
could buy a listed CA key.

All CA in the CTL are “equally” trusted. The security of any certificate is reduced to that
of the least trustworthy CA (allowing for certificate masquerades).

Cross-Certification

X.509 PKI CA trust models include a single CA model (one trusted root CA), distributed
CA models (many trusted root CAs), a subordinate hierarchical model (a root CA that
issue certificates to its subordinate CAs). The distributed CA model gives raise to cross-
certification; RFC3280 defines cross-certification as “…Two CAs exchange information
used in establishing a cross-certificate. A cross-certificate is a certificate issued by one
CA to another CA which contains a CA signature key used for issuing certificates…”

Each end user has one, trusted CA that is the start of any certificate verification path.
Two entities wishing to communicate must have a common trusted CA. A certificate
chain is an ordered list of certificates containing an end-user subscriber Certificate and
CA Certificates, which terminates in a root Certificate.

A user would need to review the legal and contractual documents from the trusted CA
and from all the CAs with which the trusted CA entered into cross-certification. Even if

16
the user had “good reason to trust” a given CA policy composition could make such trust
misplaced.

Such review process is much too difficult or if not outright impossible. There isn’t
agreement on what documents need to be use as the basis for CAs cross-certification.
Moreover, there isn’t universal agreement on the role of CPs, CPSs, CRL Usage
Agreement, etc.; on the different PKI domains of application and they don’t constitute a
de-facto base documentation for cross-certification. Some CPs and CPSs are public
domain documents (SSL certification), but private, governmental, or military CAs may
consider its CPs and CPSs extremely sensitive document. What documents are to be used
as part of a cross-certification agreement, which ones can provide a basis for inter-
operability, harmonization of terminology and practices, etc.; it still debated today. Some
CAs are resorting to PKI Disclosure Statements as a basis for cross-certification [97].

CA cross-certification can create disjoint hierarchies with multiple paths leading from a
given leaf certificate, with different processing rules (different validity periods,
constraints, etc.); certificate revocation and re-issuance, etc., turn in the words of Peter
Gutmann [49] “…The Web of Trust in the Spaghetti of Doubt…”

CAs’ CPS - Liability

The potential value of a certificate and the implied trust to its holder while hard to assess
can be very large. Most CAs either deny any liability or set strict limits.

VeriSign ECA CPS [93] states: “…2.2.2.2 General Warranty Disclaimer EXCEPT AS
SET FORTH IN THE ECA CP AND THIS CPS AND THE APPLICABLE
SUBSCRIBER AGREEMENT, AND TO THE EXTENT PERMITTED BY
APPLICABLE LAW, VERISIGN DISCLAIMS ANY AND ALL OTHER EXPRESS
OR IMPLIED WARRANTIES OF ANY TYPE TO ANY PERSON OR ENTITY,
INCLUDING ANY WARRANTY OF MERCHANTABILITY, ANY WARRANTY OF
FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTY OF THE
ACCURACY OF INFORMATION PROVIDED BY CERTIFICATE APPLICANTS,
SUBSCRIBERS, AND THIRD PARTIES…”
Compare this practice with that of most US retail banks: if a card is reported lost within 2
days the cardholder isn’t liable for any fraudulent charges, if a card is reported stolen
within 2-60 days the cardholder is liable for $50.

Compromising a CA Private Key

If a CA private key is compromised the integrity of any (valid) certificate issued and
signed by the key may be compromised. The CA may need to revoke all associated
(valid) certificates and publish a CRL (including the revoked CA certificate) signed with
a new private key

To reduce the impact on the customer base CAs may have multiple key pairs and a key
rotation scheme. The CA distributes the certificates across its multiple keys [11, 38, 45,
92].

17
CA key revocation problems are multiple: secure notification of CA key compromise,
efficient notification of CA key compromise, CRL update (listing all compromised
certificates), CRL download (of all compromised certificates), (new) certificate issuance,
(new) CA key distribution.

User Private Key Control and Storage

User private keys are stored in personal computers. These personal computers aren’t
trusted computing platforms. Even if they were it is unlikely that the user can guarantee
he is the only one with access to the computer. Non-repudiation (of digital signatures) is
compromised under current PKI private store implementations. It is not possible to hold
users accountable for private key use.

Unfortunately non-repudiation (of digital signatures) has been legislated on some states.
As long as a “message” was signed with my private key I am responsible.

Compare this to a credit card user repudiating an item on his bill: the merchant is required
to prove the purchase.

Other key management issues (not fully resolve) include (secure) key backup/archival,
key destruction (all copies of the private key must be destroyed but the public key may
need to remain available), what happened when a CA goes out of business, etc.
X.509 Implementation Issues

X.509 Implementation Issues

The X.509v3 standard encoding rules and flexibility (one size fits all character) coupled
with the (different) profiles have made significantly difficult its implementation.

Some well known problems include: different encoding rules (BER, DER), tagging
implicit/explicit use confused within a profile and between profiles (TBSCertificate),
serial numbers are supposed to be (positive) integers (32 bit) but some implementations
use larger numbers (VeriSign uses 128 or 160 bit hashes; Microsoft at some time
generated negative serial numbers), DN required attributes vary between
implementations, etc.

Microsoft Certificate Server creates DER encoded certificates. Netscape Navigator expets
Base64 encoded ones [98].

SSL Certificates

X.509 PKI was proposed and adopted as an authentication technology for users to
authenticate servers and vice versa. SSL and TLS rely on X.509 PKI for authentication.
While SSL (and TLS) support mutual authentication typically only the servers are
authenticated. There is currently no mechanism available to widely deploy signed
personal certificates.

18
Browser (and other Applications) X.509 PKI Implementation Problems

Browsers and user/server interaction are easily compromised even with a working X.509
PKI. Dhamija and Tygar [30] state that “…current browser and related application
programs have not been carefully designed with “security usability” in mind…” They
argue regarding browsers that their designers have not taking into account human
strengths and limitations when designing the user interface including: the human
tendency to trust known entities (brands, logos, etc.), users inability to reliably parse
domain names, users inability to reliably distinguish hyperlinks from images of
hyperlinks, users inability to reliably distinguish browser chrome from web page content,
users inability to reliably distinguish actual security indicators from images of those
indicators, users lack of understanding of certificates and PKI, etc.

Implementation problems make a X.509 PKI an even more elusive goal: browsers may
not perform on-line certificate revocation checks, when configured to do so and failing to
access a CRL browsers may proceed as if it the certificate were valid, it is possible for
users to configure their browsers to bypass revocation checks, “untrusted” CAs can be
easily added by malware, etc.

Microsoft Knowledge Base Article 241008 [67] states that “…Beginning with Outlook
Express 5.01, certificate revocation checking is disabled by default…”

Microsoft Knowledge Base Article 258727 [68] states that “…client may still
successfully authenticate to the IIS computer even when the client certificate has been
revoked…”

Microsoft Knowledge Base Article 264862 [69] states that when configuring Exchange
5.5 Key Management Server to use Windows 2000 Certificate Server, the X.509 V3
certificate message client receive may be missing the CRL distribution point.

Cisco Security Advisory Document ID 66142 [25] states “…A malicious attacker may be
able to spoof a Cisco Intrusion Detection Sensor (IDS), or Cisco Intrusion Prevention
System (IPS) by exploiting a vulnerability in the SSL certificate checking functionality in
IDSMC and Secmon…”

Cisco Security Advisory Document ID 63178 [27] states “… A Cisco Secure Access
Control Server (ACS) that is configured to use Extensible Authentication Protocol-
Transport Layer Security (EAP-TLS) to authenticate users to the network will allow
access to any user that uses a cryptographically correct certificate as long as the user
name is valid. Cryptographically correct means that the certificate is in the appropriate
format and contains valid fields. The certificate can be expired, or come from an
untrusted Certificate Authority (CA) and still be cryptographically correct…”

Cisco Security Advisory Document ID 66280 [28] states “…The Cisco CSS 11500 Series
Content Services Switches (CSS) running Secure Socket Layer (SSL) has a vulnerability
that may allow a user to bypass SSL authentication and access protected content…”

19
Secunia reported on August 2004 [86] a GnuTLS X.509 vulnerability “…due to an error
when verifying X.509 certificate signatures. This can be exploited by passing a long
certificate chain containing…” capable of producing a DOS (that effected multiple open
source products).

SecurityFocus reported on August 2002 [87] multiple vendor invalid X.509 certificate
chain vulnerability “…A flaw has been reported in the handling of X.509 certificates by a
number of products, including several web browsers. It may be possible for a malicious
party to create certificates for arbitrary domains, which will be treated as trusted by the
vulnerable browser…” Vendors effected included Avaya, BEA Systems, KDE,
Microsoft, etc.

SecuritySpace reported on February 2006 [88] “…Several flaws were found in the way
libtasn1 decodes DER. An attacker could create a carefully crafted invalid X.509
certificate in such a way that could trigger this flaw if parsed by an application that uses
GNU TLS. This could lead to a denial of service (application crash). It is not certain if
this issue could be escalated to allow arbitrary code execution…”

For other X.509 PKI vulnerabilities see Mozilla [23], Nai [71], OpenSSL [21], Sun [20],
and visit the sites of Cisco, Microsoft, SecurityFocus, etc.

13. Conclusions

In this paper we review X.509 style PKI, a technology whose proponents argue would
deliver the secure authentication and access controls needed for e-commerce, secure e-
mail, and many other environments and applications. X.509 PKI was originally
conceived as an access control technology for X.500 directories. It evolved into a general
purpose authentication and access control technology for a wide range of applications and
environments while retaining (most) of its architectural heritage. Attempts to fit the world
into X.509 PKI had made the technology too flexible, exceedingly complex, and
expensive.

14. References

[1] 1st Annual PKI Research Workshop---Proceedings; NIST; April 2002

[2] 2nd Annual PKI Research Workshop Pre-Proceedings;
http://middleware.internet2.edu/pki03/; March 12, 2006
[3] Adams C.; Understanding PKI: Concepts, Standards, and Deployment
Considerations; Second Edition; Addison-Wesley; Boston, MA; 2002
[4] AADS, Account Authority Digital Signature Model;
http://www.puffin.com/~lynn/aadsover.htm; March 31, 2006
[5] ABDS/AADS; http://www.garlic.com/~lynn/; March 31, 2006
[6] Adams C., Ankney R., Galperin S., Malpani A., Myers M.; X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol – OCSP; RFC2560; June 1999

20
[7] Adams C., Blinov M.; Alternative Certificate Formats for the Public-Key
Infrastructure Using X.509 (PKIX) Certificate Management Protocols; RFC4212;
October 2005
[8] Adams C., Burmester M., Desmedt Y., Which PKI (Public Key Infrastructure) is the
Right One?; ACM 1-58113-203-4/00/0011
[9] Adams C., Farrell S., Kause T., Mononen T.; Internet X.509 Public Key
Infrastructure Certificate Management Protocol (CMP); RFC 4210; September 2005
[10]Adams C., Sylvester P., Zolotarev M., Zuccherato R.; Internet X.509 Public Key
Infrastructure Data Validation and Certification Server Protocols; RFC3029; February
2001
[11]ARIN; Certification Practice Statement; OID 1.3.6.1.4.1.18428.1.1.2; October 2004
[12]Balenson D.; Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms,
Modes, and Identifiers; RFC 1423; February 1993
[13]Barzin P., Nystrom M., Polk W., Santesson S.; Internet X.509 Public Key
Infrastructure Qualified Certificates Profile; RFC3039; January 2001
[14]Bassham L., Housley R. , Polk W. ; Algorithms and Identifiers for the Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile; RFC3279; April 2002
[15]Benson Carol C.; Glenbrook Partners; Preventing Identity Theaf Banker, Heal
Thyself; GlenBrook Partners; May 2004
[16]Bishop Matt; “Computer Security Art and Science”; Addison-Wesley; Boston, MA;
2003
[17]Boeyen S., Hallam-Baker P.; Internet X.509 Public Key Infrastructure Repository
Locator Service; RFC4386; February 2006
[18]Bonilla R.; Slagell A.; PKI Scalability Issues; arXiv:cs.CR/0409018 V2; Nov 2005
[19]Cauvoukian Ann; Identity Theft Revisited: Security Is Not Enoguh; Information and
Privacy Commisiner/Ontario; September 2005
[20]CERT US; Advisory CA-2000-19 Revocation of Sun Microsystems Browser
Certificates; http://cert.surfnet.nl/s/2000/S-00-48.htm; March 26, 2006
[21]CERT UK ; Vulnerability Note VU#234971; mod_ssl and Apache_SSL modules
contain a buffer overflow in the implementation of the OpenSSL
"i2d_SSL_SESSION" routine; http://www.kb.cert.org/vuls/id/234971; March 26,
2006
[22]CERT UK; Vulnerability Note VU#399087; Internet Explorer incorrectly validates
certificates when CRL checking is enabled; http://www.kb.cert.org/vuls/id/399087;
March 26, 2006
[23]CERT UK; Vulnerability Note VU#784278; Mozilla fails to validate the DN of
X.509 certificates; http://www.kb.cert.org/vuls/id/784278; March 26, 2006
[24]Chokhani S., Ford W., Merrill C., Sabett R., S. Wu; Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices
Framework; RFC3647;November 2003
[25]Cisco; SSL Certificate Validation Vulnerability in IDS Management Software,
Document 66142;
http://www.cisco.com/en/US/customer/products/products_security_advisory09186a0
0804fa92e.shtml; March 26, 2006
[26]Cisco; 11500 Content Services Switch SSL Malformed Client Certificate
vulnerability; Document 67919;

21
 http://www.cisco.com/en/US/customer/products/products_security_advisory09186a0
08054bc9b.shtml; March 26, 2006
[27]Cisco; Security Advisory: Vulnerability in Cisco Secure Access Control Server EAP-
TLS Authentication; Document 63178;
http://www.cisco.com/en/US/customer/products/products_security_advisory09186a0
08033320e.shtml; March 26, 2006
[28]Cisco; Security Notice: CSS SSL Authentication Bypass; Document 66280;
http://www.cisco.com/en/US/customer/products/hw/contnetw/ps792/products_securit
y_notice09186a0080512ff7.html; March 26, 2006
[29]Cooper M., Dzambasow Y., Hesse P., Joseph S., Nicholas R.; Internet X.509 Public
Key Infrastructure: Certification Path Building; RFC4158; September 2005
[30]Dhamija R.; Tygar J. D.; The Battle Against Phishing: Dynamic Security Skins;
SOUP; July 2005
[31]Whitfield D., Hellman M. E.; New Directions in Cryptography; IEEE Information
Theory Workshop; Lenox, MA; June 23-25, 1975
[32]Ellison Carl; Naming and Certificates
[33]Ellison Carl; Et al; SPKI Requirements; RFC 2692; September 1999
[34]Ellsion Carl; What do you need to know about the person with whom you are doing
business?; House Science and Technology Subcommitte; Hearing of 28 October
1997: Signatures in a Digital Age; Written Testimony of Carl Ellison;
[35]Ellison Carl; Et al; SPKI Certificate Theory; RFC 2693; September 1999
[36]Ellison Carl; Schneier Bruce; Risks of PKI: E-Commerce; Communications of the
ACM; Vol. 43, No. 2; February 2000
[37]Ellison Carl; Schneier Bruce; Risks of PKI: Secure Email; Communications of the
ACM; Vol. 43, No. 1; January 2000
[38]Entrust; X.509 Profiles for Various CA Scenarios Version 3.0; June 2004
[39]Essiari A., Mudumbai S, Thomson Mary R.; Certificate-Based Authorization Policy
in a PKI Environment; Lawrence Berkeley National Laboratory; ACM Transactions
on Information and Systems Security; Vol. 6, No. 4; November 2008, Pages 566-588
[40]Fono R., Feinbloom W.; A Matter of Trusting Trust; Essay # 2001-01; March 2001
[41]Fono R., Feinbloom W.; PKI: A Question of Trust and Value; Communications of
the ACM; Vol. 44, No. 6; June 2001
[42]Ford W., Housley R., Polk W., Solo D.; Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile; RFC3280; April 2002
[43]GAO, Report to the Chairman, Subcommittee on Government Efficiency, Financial
Management and Intergovermental Reform, House of Representaties; Information
Security; Advances and Remaining Challenges to Adoption of Public Key
infrastructure Technology; GAO-01-277; February 2001
[44]Garfinkel Simson L.; Email-Based Identification and Authentication: An Alternative
to PKI?; IEEE Security and Privacy; 2003
[45]GeoTrust; Vulnerability of First-Generation Digital Certificates and Potential for
Phishing Attacks and Consumer Fraud; 2005
[46]Gossels Jon; Identity Theft and the Renewed Fcous on Authentication; The ISSA
Journal; May 2005
[47]Guida Rich; Adoption of PKI
[48]Gutmann P.; Encryption and Security Tutorial; University of Auckland
[49]Gutmann P.; Everything You Never Wanted to Know About PKI but were Forced to
Find Out; University of Auckland

22
[50]Gutmann P., Ed; Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access; RFC4387; February 2006
[51]Gutmann P.; Key Management and Certificates; University of Auckland
[52]Gutmann P.; Plug-and-Play PKI: A PKI your Mother can Use; University of
Auckland
[53]Gutmann P.; PKI: It’s Not Dead, Just Resting; IEEE; August 2002
[54]Gutmann P.; X.509 Style Guide; University of Auckland
[55]Henry David; Who’s Got the Key?; SIGUCCS 99; ACM 1-58113-144-5/99/0011;
1999
[56]Housley R., Santesson S.; Internet X.509 Public Key Infrastructure Authority
Information Access Certificate Revocation List (CRL) Extension; RFC4325;
December 2005
[57]Howell J., Kotz D.; End-to-end Authorization; Darmouth College; Department of
Computer Science;
[58]Howes Timtothy A., Smith Mark C., Good Gordon S.; Understanding and Deploying
LDAP Directory Services; Second Edition; Addison-Wesley; Boston, MA; 2003
[59]Hu Yuh-Jong; Some Thoughts on Agent Trust and Delegation; Agents’01; ACM 1-
58113-326-X/01/0005; May 28-June 1 2001
[60]Jha S.; From Authentication to Authorization; University of Wisconsin; Computer
Sciences Department; February 2001
[61]Kent S.; Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based
Key Management; RFC 1422; February 1993
[62]Koc C.; Account Based Electronic Payment; Oregon State University and
CryptoVision GmbH; November 2000
[63]Kohnfelder Loren; Towards a Practical Public-Key Cryptosystem; MIT; May 1978
[64]Levy I.; Identity Based PKC – Potential Applications; CESG
[65]Linn J.; Privacy Enhancement for Internet Electronic Mail: Part I: Message
Encryption and Authentication Procedures; RFC 1421; February 1993
[66]Lynn C., Kent S., Seo K.; X.509 Extensions for IP Addresses and AS
Identifiers; RFC3779; June 2004
[67]Microsoft; Knowledge Base; Article Q241008; OLEXP: Description of Certificate
Revocation Behavior in Outlook Express http://support.microsoft.com/kb/241008/en-
us; March 31, 2006
[68]Microsoft; Knowledge Base; Article Q258727; Web Site Accepts Revoked
Certificates; http://support.microsoft.com/kb/258727/en-us; March 31, 2006
[69]Microsoft; Knowledge Base; Article Q264862; XADM: No Certificate Revocation
List Distribution Points Extension in X.509 V3 Certificate;
http://support.microsoft.com/kb/264862/en-us; March 31, 2006
[70]Microsoft; Security Bulletin MS01-017;
http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx;March 12, 2006
[71]NAi Net Tools PKI Server Vulnerabilities;
http://seclists.org/lists/bugtraq/2000/Aug/0040.html; March 12, 2006
[72]Neuman Peter G.; Weinstein L; Risks of National Identity Cards; Communications of
the ACM; Vol. 44, No. 12; December 2001
[73]NIST; Electronic Authentication Guideline; NIST Publication 800-63 Version 1.0.1;
September 2004
[74]Mockapetris, P., "Domain names - concepts and Facilities", STD 13, RFC 1034;
November 1987

23
[75]Nykanen Toni; Attribute Certificates in X.509; Helsinki University of Technology;
Department of Computer Science and Engineering; 2000
[76]Nystrom M., Polk T., Santesson S.; Internet X.509 Public Key Infrastructure:
Qualified Certificates Profile; RFC3739; Mar 2004
[77]O’Higgins B.; PKI Is Geeting Rediscovered; February 2003
[78]OMG; Public Key Infrastructure Specification Version 1.0; September 2002
[79]Pearson Mike; PKI – Reality v. Hype Where to Draw the Line; E-government Unit;
State Services Commission, New Zealand
[80]Peha J.; Khamitov M.; PayCash: A Secure Effiecient Internet Payment System; ACM
1-58113-788-5/03/09
[81]Penev T.; Identity Based Public Key Infrastructures; Department of Informatics;
Darmstadt University of Technology; August 2005
[82]PKI Primer; Internet 2 PKI Conference;
[83]Perrin Trevor; Public Key Distribution through “cryptoIDs”; New Security
Paradigms Wrokshop; ACM 1-58113-880-6/04/04; 2003
[84]Riha Z.; Certification; FI MU Report Series; FIMU-RS-98-07; December 1998
[85]Schaad J.; Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF); RFC4211; Sep 2005
[86]Secunia; Advisories; SA12156 GnuTLS X.509 Certificate Signature Verification
Denial of Service; 08-03-2004; http://secunia.com/advisories/12156/; March 31,
2006
[87]SecurityFocus; Bugtraq ID 5410; Multiple Vendor Invalid X.509 Certificate Chain
Vulnerability; Auguts 06 2006; http://www.securityfocus.com/bid/5410/info; March
31, 2006
[88]SecuritySpace; FLSA-2006:181014;
http://www.securityspace.com/smysecure/catid.html?id=56347; March 31, 2006
[89]Sleve T.; Hoogenboom M.; Who Will Rob You on the Digital Highway?;
Communications of the ACM; Vol. 47, No. 5; May 2004
[90]Tjostheim T; A Critical View of PKI Infrastructures; Institute of Informatics;
University of Bergen; February 2004
[91]VerSign, Inc; Advisory January 2001;
http://www.verisign.com/support/advisories/authenticodefraud.html; March 12, 2006
[92]VeriSign; DOD IECA Certification Practice Statement Version 3.0; February 2002
[93]VeriSign; External Certification Authority Certification Practice Statement Version
1.0; 31 Jan 2005
[94]VerSign, Inc; News & Events; VeriSign Update on Certificate Revocation List
Expiration January 9, 2004
http://www.verisign.com/verisign-inc/news-and-events/news-archive/us-news-
2004/page_000738.html; March 12 2006
[95]VeriSign inc; http://crl.verisign.com/; March 26, 2006
[96]VeriSign, Inc; CRL Usage Agreement;
http://crl.verisign.com/CRL%20Usage%20Agreement.txt; March 12, 2006
[97]VeriSign, Inc; PKI Disclosure Statement;
http://www.verisign.com/repository/disclosure.html; March 12, 2006
[98]Microsoft, Knowledge Base; Article Q230227; How to Use Certificate Server-
Generated CA Certificates with Netscape Navigator
http://support.microsoft.com/kb/230227/en-us; March 31, 2006

24