Public key

infrastructure

Diagram of a public key infrastructure

A public key infrastructure (PKI) is a

set of roles, policies, and procedures
needed to create, manage, distribute,
use, store, and revoke digital
certificates and manage public-key
encryption. The purpose of a PKI is to
facilitate the secure electronic transfer
of information for a range of network
activities such as e-commerce, internet
banking and confidential email. It is
required for activities where simple
passwords are an inadequate
authentication method and more
rigorous proof is required to confirm
the identity of the parties involved in
the communication and to validate the
information being transferred.[1]

In cryptography, a PKI is an
arrangement that binds public keys
with respective identities of entities
(like people and organizations). The
binding is established through a
process of registration and issuance of
certificates at and by a certificate
authority (CA). Depending on the
assurance level of the binding, this may
be carried out by an automated
process or under human supervision.

The PKI role that assures valid and

correct registration is called a
registration authority (RA). An RA is
responsible for accepting requests for
digital certificates and authenticating
the entity making the request.[2] In a
Microsoft PKI, a registration authority
is usually called a subordinate CA.[3]

An entity must be uniquely identifiable

within each CA domain on the basis of
information about that entity. A third-
party validation authority (VA) can
provide this entity information on
behalf of the CA.
Design
Public key cryptography is a
cryptographic technique that enables
entities to securely communicate on an
insecure public network, and reliably
verify the identity of an entity via digital
signatures.[4]

A public key infrastructure (PKI) is a

system for the creation, storage, and
distribution of digital certificates which
are used to verify that a particular
public key belongs to a certain entity.
The PKI creates digital certificates
which map public keys to entities,
securely stores these certificates in a
central repository and revokes them if
needed.[5][6][7]

A PKI consists of:[6][8][9]

A certificate authority (CA) that

stores, issues and signs the digital
certificates
A registration authority which verifies
the identity of entities requesting
their digital certificates to be stored
at the CA
A central directory—i.e., a secure
location in which to store and index
 keys
A certificate management system
managing things like the access to
stored certificates or the delivery of
the certificates to be issued.
A certificate policy stating the PKI's
requirements concerning its
procedures. Its purpose is to allow
outsiders to analyze the PKI's
trustworthiness.

Methods of certification
Broadly speaking, there have
traditionally been three approaches to
getting this trust: certificate authorities
(CAs), web of trust (WoT), and simple
public key infrastructure (SPKI).

Certificate authorities

The primary role of the CA is to digitally

sign and publish the public key bound
to a given user. This is done using the
CA's own private key, so that trust in
the user key relies on one's trust in the
validity of the CA's key. When the CA is
a third party separate from the user and
the system, then it is called the
Registration Authority (RA), which may
or may not be separate from the CA.[10]
The key-to-user binding is established,
depending on the level of assurance
the binding has, by software or under
human supervision.

The term trusted third party (TTP) may

also be used for certificate authority
(CA). Moreover, PKI is itself often used
as a synonym for a CA
implementation.[11]

Issuer market share

In this model of trust relationships, a

CA is a trusted third party – trusted
both by the subject (owner) of the
certificate and by the party relying upon
the certificate.

According to NetCraft,[12] the industry

standard for monitoring Active TLS
certificates, states that- "Although the
global [TLS] ecosystem is competitive,
it is dominated by a handful of major
CAs — three certificate authorities
(Symantec, Comodo, GoDaddy)
account for three-quarters of all issued
[TLS] certificates on public-facing web
servers. The top spot has been held by
Symantec (or VeriSign before it was
purchased by Symantec) ever since
[our] survey began, with it currently
accounting for just under a third of all
certificates. To illustrate the effect of
differing methodologies, amongst the
million busiest sites Symantec issued
44% of the valid, trusted certificates in
use — significantly more than its overall
market share."

Temporary certificates and

single sign-on

This approach involves a server that

acts as an offline certificate authority
within a single sign-on system. A single
sign-on server will issue digital
certificates into the client system, but
never stores them. Users can execute
programs, etc. with the temporary
certificate. It is common to find this
solution variety with X.509-based
certificates.[13]

Web of trust

An alternative approach to the problem

of public authentication of public key
information is the web-of-trust scheme,
which uses self-signed certificates and
third party attestations of those
certificates. The singular term "web of
trust" does not imply the existence of a
single web of trust, or common point of
trust, but rather one of any number of
potentially disjoint "webs of trust".
Examples of implementations of this
approach are PGP (Pretty Good
Privacy) and GnuPG (an
implementation of OpenPGP, the
standardized specification of PGP).
Because PGP and implementations
allow the use of e-mail digital
signatures for self-publication of public
key information, it is relatively easy to
implement one's own web of trust. [14]
One of the benefits of the web of trust,
such as in PGP, is that it can
interoperate with a PKI CA fully trusted
by all parties in a domain (such as an
internal CA in a company) that is willing
to guarantee certificates, as a trusted
introducer. If the "web of trust" is
completely trusted then, because of the
nature of a web of trust, trusting one
certificate is granting trust to all the
certificates in that web. A PKI is only as
valuable as the standards and
practices that control the issuance of
certificates and including PGP or a
personally instituted web of trust could
significantly degrade the trustability of
that enterprise's or domain's
implementation of PKI.[15]

The web of trust concept was first put

forth by PGP creator Phil Zimmermann
in 1992 in the manual for PGP version
2.0:

As time goes on, you will

accumulate keys from other
people that you may want to
designate as trusted
introducers. Everyone else will
each choose their own trusted
introducers. And everyone will
gradually accumulate and
distribute with their key a
collection of certifying
signatures from other people,
with the expectation that
anyone receiving it will trust
at least one or two of the
signatures. This will cause the
emergence of a decentralized
fault-tolerant web of
confidence for all public keys.
Simple public key
infrastructure

Another alternative, which does not

deal with public authentication of
public key information, is the simple
public key infrastructure (SPKI) that
grew out of three independent efforts
to overcome the complexities of X.509
and PGP's web of trust. SPKI does not
associate users with persons, since the
key is what is trusted, rather than the
person. SPKI does not use any notion
of trust, as the verifier is also the
issuer. This is called an "authorization
loop" in SPKI terminology, where
authorization is integral to its design.

Blockchain-based PKI

An emerging approach for PKI is to use

the blockchain technology commonly
associated with modern
cryptocurrency. Since blockchain
technology aims to provide a
distributed and unalterable ledger of
information, it has qualities considered
highly suitable for the storage and
management of public keys. Emercoin
is an example of a blockchain-based
cryptocurrency that supports the
storage of different public key types
(SSH, GPG, RFC 2230, etc.) and
provides open source software that
directly supports PKI for OpenSSH
servers. While blockchain technology
can approximate the "proof of work"
often underpinning the confidence in
trust that relying parties have in a PKI,
issues remain such as administrative
conformance to policy, operational
security and software implementation
quality. A Certificate Authority
paradigm has these issues regardless
of the underlying cryptographic
methods and algorithms employed, and
PKI that seeks to endow certificates
with trustworthy properties must also
address these issues.

History
Developments in PKI occurred in the
early 1970s at the British intelligence
agency GCHQ, where James Ellis,
Clifford Cocks and others made
important discoveries related to
encryption algorithms and key
distribution.[16] However, as
developments at GCHQ are highly
classified, the results of this work were
kept secret and not publicly
acknowledged until the mid-1990s.

The public disclosure of both secure

key exchange and asymmetric key
algorithms in 1976 by Diffie, Hellman,
Rivest, Shamir, and Adleman changed
secure communications entirely. With
the further development of high-speed
digital electronic communications (the
Internet and its predecessors), a need
became evident for ways in which
users could securely communicate
with each other, and as a further
consequence of that, for ways in which
users could be sure with whom they
were actually interacting.

Assorted cryptographic protocols were

invented and analyzed within which the
new cryptographic primitives could be
effectively used. With the invention of
the World Wide Web and its rapid
spread, the need for authentication and
secure communication became still
more acute. Commercial reasons alone
(e.g., e-commerce, online access to
proprietary databases from web
browsers) were sufficient. Taher
Elgamal and others at Netscape
developed the SSL protocol ('https' in
Web URLs); it included key
establishment, server authentication
(prior to v3, one-way only), and so on. A
PKI structure was thus created for Web
users/sites wishing secure
communications.

Vendors and entrepreneurs saw the

possibility of a large market, started
companies (or new projects at existing
companies), and began to agitate for
legal recognition and protection from
liability. An American Bar Association
technology project published an
extensive analysis of some of the
foreseeable legal aspects of PKI
operations (see ABA digital signature
guidelines), and shortly thereafter,
several U.S. states (Utah being the first
in 1995) and other jurisdictions
throughout the world began to enact
laws and adopt regulations. Consumer
groups raised questions about privacy,
access, and liability considerations,
which were more taken into
consideration in some jurisdictions
than in others.
The enacted laws and regulations
differed, there were technical and
operational problems in converting PKI
schemes into successful commercial
operation, and progress has been much
slower than pioneers had imagined it
would be.

By the first few years of the 21st

century, the underlying cryptographic
engineering was clearly not easy to
deploy correctly. Operating procedures
(manual or automatic) were not easy to
correctly design (nor even if so
designed, to execute perfectly, which
the engineering required). The
standards that existed were
insufficient.

PKI vendors have found a market, but it

is not quite the market envisioned in
the mid-1990s, and it has grown both
more slowly and in somewhat different
ways than were anticipated.[17] PKIs
have not solved some of the problems
they were expected to, and several
major vendors have gone out of
business or been acquired by others.
PKI has had the most success in
government implementations; the
largest PKI implementation to date is
the Defense Information Systems
Agency (DISA) PKI infrastructure for
the Common Access Cards program.

Uses
PKIs of one type or another, and from
any of several vendors, have many
uses, including providing public keys
and bindings to user identities which
are used for:

Encryption and/or sender

authentication of e-mail messages
(e.g., using OpenPGP or S/MIME)
Encryption and/or authentication of
documents (e.g., the XML Signature
or XML Encryption standards if
documents are encoded as XML)
Authentication of users to
applications (e.g., smart card logon,
client authentication with SSL).
There's experimental usage for
digitally signed HTTP authentication
in the Enigform and mod_openpgp
projects
Bootstrapping secure
communication protocols, such as
Internet key exchange (IKE) and SSL.
In both of these, initial set-up of a
secure channel (a "security
association") uses asymmetric key—
i.e., public key—methods, whereas
actual communication uses faster
symmetric key—i.e., secret key—
methods.
Mobile signatures are electronic
signatures that are created using a
mobile device and rely on signature
or certification services in a location
independent telecommunication
environment[18]
Internet of things requires secure
 communication between mutually
trusted devices. A public key
infrastructure enables devices to
obtain and renew X509 certificates
which are used to establish trust
between devices and encrypt
communications using TLS

Open source
implementations
OpenSSL is the simplest form of CA
and tool for PKI. It is a toolkit,
developed in C, that is included in all
major Linux distributions, and can be
used both to build your own (simple)
CA and to PKI-enable applications.
(Apache licensed)
EJBCA is a full featured, Enterprise
grade, CA implementation developed
in Java. It can be used to set up a CA
both for internal use and as a
service. (LGPL licensed)
OpenCA is a full featured CA
implementation using a number of
different tools. OpenCA uses
OpenSSL for the underlying PKI
operations.
XCA is a graphical interface, and
database. XCA uses OpenSSL for the
 underlying PKI operations.
(Discontinued) TinyCA was a
graphical interface for OpenSSL.
XiPKI,[19] CA and OCSP responder.
With SHA3 support, OSGi-based
(Java).
IoT_pki is a simple PKI built using
the python cryptography library
DogTag is a full featured CA
developed and maintained as part of
the Fedora Project.

Criticism
Some argue that purchasing
certificates for securing websites by
SSL and securing software by code
signing is a costly venture for small
businesses.[20]. However, the
emergence of free alternatives such as
Let's Encrypt, has changed this.
Presently Symantec holds a major
share in PKI certificate market which
sold one third of all certificates issued
globally in 2013.[21] HTTP/2, the latest
version of HTTP protocol allows
unsecured connections in theory, in
practice major browser companies
have made it clear that they would
support this state-of-art protocol only
over a PKI secured TLS connection.[22]
Web browser implementation of
HTTP/2 including Edge from Microsoft,
Chrome from Google, Firefox from
Mozilla, and Opera supports HTTP/2
only over TLS by using ALPN extension
of TLS protocol. This would mean that
to get the speed benefits of HTTP/2,
website owners would be forced to
purchase SSL certificates controlled by
corporations such as Symantec.

Current web browsers carry pre-

installed intermediary certificates
issued and signed by a Certificate
Authority. This means browsers need
to carry a large number of different
certificate providers, increasing the risk
of a key compromise.

When a key is known to be

compromised it could be fixed by
revoking the certificate, but such a
compromise is not easily detectable
and can be a huge security breach.
Browsers have to issue a security patch
to revoke intermediary certificates
issued by a compromised root
certificate authority.[23] Some practical
security vulnerabilities of X.509
certificates and known cases where
keys were stolen from a major
Certificate Authority listed below.

See PKI security issues with X.509

See Breach of Comodo CA
See Breach of Diginotar CA

See also
Certificate-Less Authenticated
Encryption

References
1. "What is a Public Key Infrastructure -
A Simple Overview , April 17, 2015" .
2. "An Overview of Public Key
Infrastructures (PKI)" . Techotopia.
Retrieved 26 March 2015.
3. "Public Key Infrastructure" . MSDN.
Retrieved 26 March 2015.
4. Adams, Carlisle & Lloyd, Steve (2003).
Understanding PKI: concepts,
standards, and deployment
considerations . Addison-Wesley
Professional. pp. 11–15. ISBN 978-0-
672-32391-1.
5. Trček, Denis (2006). Managing
information systems security and
privacy . Birkhauser. p. 69. ISBN 978-3-
540-28103-0.
6. Vacca, Jhn R. (2004). Public key
infrastructure: building trusted
applications and Web services . CRC
Press. p. 8. ISBN 978-0-8493-0822-2.
7. Viega, John et al. (2002). Network
Security with OpenSSL . O'Reilly Media.
pp. 61–62. ISBN 978-0-596-00270-1.
8. McKinley, Barton (January 17, 2001).
"The ABCs of PKI: Decrypting the
complex task of setting up a public key
infrastructure" . Network World.
9. Al-Janabi, Sufyan T. Faraj et al.
(2012). "Combining Mediated and
Identity-Based Cryptography for
Securing Email". In Ariwa, Ezendu et al.
Digital Enterprise and Information
Systems: International Conference, Deis,
[...] Proceedings . Springer. pp. 2–3.
10. "Mike Meyers CompTIA Security+
Certification Passport", by T. J.
Samuelle, p. 137.
11. Henry, William (4 March 2016).
"Trusted Third Party Service" .
12.
http://news.netcraft.com/archives/201
5/05/13/counting-ssl-certificates.html
13. Single Sign-On Technology for SAP
Enterprises: What does SAP have to
say? "Archived copy" . Archived from
the original on 2011-07-16. Retrieved
2010-05-25.
14. "Public Key Infrastructure" (PDF).
saylor. Retrieved 2016-08-29.
15. Ed Gerck, Overview of Certification
Systems: x.509, CA, PGP and SKIP, in
The Black Hat Briefings '99,
http://www.securitytechnet.com/resour
ce/rsc-
center/presentation/black/vegas99/cert
over.pdf and http://mcwg.org/mcg-
mirror/cert.htm
16. Ellis J. H., January 1970,The
Possibility of Secure Non-Secret Digital
Encryption Archived 2014-10-30 at the
Wayback Machine.
17. Stephen Wilson, December 2005,
"The importance of PKI today"
Archived 2010-11-22 at the Wayback
Machine., China Communications,
Retrieved on 2010-12-13
18. Mark Gasson, Martin Meints, Kevin
Warwick (2005), D3.2: A study on PKI
and biometrics , FIDIS deliverable (3)2,
July 2005
19. "xipki/xipki · GitHub" . Github.com.
Retrieved 2016-10-17.
20. Should We Abandon Digital
Certificates, Or Learn to Use Them
Effectively? , Forbes magazine
21. SSL statistics Statistics report
collected by Netcraft, an internet service
company in UK
22. HTTP/2 Frequently Asked
Questions From Github HTTP/2 wiki
23. "Microsoft Security Advisory:
Fraudulent Digital Certificates could
allow spoofing" . Microsoft. March 23,
2011. Retrieved 2011-03-24.

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Public_key_infrastructure&oldid=8292393
49"
Last edited 23 days ago by Mauls

Content is available under CC BY-SA 3.0

unless otherwise noted.