The website uses cookies to optimize your user experience. Using this website grants us the permission to collect certain information essential to the provision of our services to you, but you may change the cookie settings within your browser any time you wish. Learn more
I agree
Text direction?

Public key infrastructure

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Diagram of a public key infrastructure

A public key infrastructure (PKI) is a set of roles, policies, hardware, software 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.

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 may be delegated by a CA to assure valid and correct registration is called a registration authority (RA). Basically, an RA is responsible for accepting requests for digital certificates and authenticating the entity making the request.[1] The Internet Engineering Task Force's RFC 3647 defines an RA as "An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do not sign or issue certificates (i.e.,an RA is delegated certain tasks on behalf of a CA)."[2] While Microsoft may have referred to a Subordinate CA as an RA [3], this is incorrect according to the X.509 PKI standards. RAs do not have the signing authority of a CA and only manage the vetting and provisioning of certificates. So in the Microsoft PKI case, the RA functionality is provided either by the Microsoft Certificate Services web site or through Active Directory Certificate Services which enforces Microsoft Enterprise CA and certificate policy through certificate templates and manages certificate enrollment (manual or auto-enrollment). In the case of Microsoft Standalone CAs, the function of RA does not exist since all of the procedures controlling the CA are based on the administration and access procedure associate with the system hosting the CA and the CA itself rather than Active Directory. Most non-Microsoft commercial PKI solutions offer a stand-alone RA component.

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.

The X.509 standard defines the most commonly used format for public key certificates.[4]


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.[5]

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.[6][7][8]

A PKI consists of:[7][9][10]

  • A certificate authority (CA) that stores, issues and signs the digital certificates;
  • A registration authority (RA) 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 keys are stored and indexed;
  • 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[edit]

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).[citation needed]

Certificate authorities[edit]

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.[11] 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.[12]

Issuer market share[edit]

Ambox current red Americas.svg
Parts of this article (those related to Symantec issued certificates being gradually distrusted since 2017) need to be updated. Please update this article to reflect recent events or newly available information.
Last update: <last updated> (January 2020)

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 report from 2015,[13] the industry standard for monitoring Active Transport Layer Security (TLS) certificates, states that- "Although the global [TLS] ecosystem is competitive, it is dominated by a handful of major CAs — three certificate authorities (Symantec, Sectigo, 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."

Following to major issues in how certificate issuing were managed, all major players gradually distrusted Symantec issued certificates starting from 2017. [14] [15] [16]

Temporary certificates and single sign-on[edit]

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.[17]

Web of trust[edit]

Main article: 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.

One of the benefits of the web of trust, such as in PGP, is that it can inter-operate 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 trustworthiness of that enterprise's or domain's implementation of PKI.[18]

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[edit]

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.[citation needed] This type of PKI is specially useful for making integrations of PKI that do not rely on third parties for certificate authorization, certificate information, etc.; A good example of this is an Air-gapped network in an office.

Decentralized PKI[edit]

Decentralized Identifiers (DIDs) eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for key management, which is the standard in hierarchical PKI. In cases where the DID registry is a distributed ledger, each entity can serve as its own root authority. This architecture is referred to as decentralized PKI (DPKI).[19][20]

Blockchain-based PKI[edit]

An emerging approach for PKI is to use the blockchain technology commonly associated with modern cryptocurrency.[21][22] 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. Some cryptocurrencies support the storage of different public key types (SSH, GPG, RFC 2230, etc.) and provides open source software that directly supports PKI for OpenSSH servers.[citation needed] 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.

Here is a list of known Blockchain-based PKI:


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.[26] Because 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.[27] 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.


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:

Open source implementations[edit]

  • 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)
  • XiPKI,[29] CA and OCSP responder. With SHA3 support, implemented in Java. (Apache 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.
  • 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.
  • CFSSL[30][31] open source toolkit developed by CloudFlare for signing, verifying, and bundling TLS certificates. (BSD 2-clause licensed)
  • Vault[32] tool for securely managing secrets (TLS certificates included) developed by HashiCorp. (Mozilla Public License 2.0 licensed)
  • Libhermetik is a self-contained public-key infrastructure system embedded in a C-language library. Hermetik utilizes LibSodium for all cryptographic operations, and SQLite for all data persistence operations. The software is open-source and released under the ISC license.


Some argue that purchasing certificates for securing websites by SSL and securing software by code signing is a costly venture for small businesses.[33] However, the emergence of free alternatives such as Let's Encrypt, has changed this. 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 protocol only over a PKI secured TLS connection.[34] 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.

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[citation needed].

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.[35] Some practical security vulnerabilities of X.509 certificates and known cases where keys were stolen from a major Certificate Authority are listed below.

See also[edit]


  1. ^ "An Overview of Public Key Infrastructures (PKI)". Techotopia. Retrieved 26 March 2015.
  2. ^ "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework". IETF. Retrieved 26 August 2020.
  3. ^ "Public Key Infrastructure". MSDN. Retrieved 26 March 2015.
  4. ^ "Using Client-Certificate based authentication with NGINX on Ubuntu - SSLTrust". SSLTrust. Retrieved 13 June 2019.
  5. ^ Adams, Carlisle; Lloyd, Steve (2003). Understanding PKI: concepts, standards, and deployment considerations. Addison-Wesley Professional. pp. 11–15. ISBN 978-0-672-32391-1.
  6. ^ Trček, Denis (2006). Managing information systems security and privacy. Birkhauser. p. 69. ISBN 978-3-540-28103-0.
  7. ^ a b Vacca, Jhn R. (2004). Public key infrastructure: building trusted applications and Web services. CRC Press. p. 8. ISBN 978-0-8493-0822-2.
  8. ^ Viega, John; et al. (2002). Network Security with OpenSSL. O'Reilly Media. pp. 61–62. ISBN 978-0-596-00270-1.
  9. ^ McKinley, Barton (January 17, 2001). "The ABCs of PKI: Decrypting the complex task of setting up a public key infrastructure". Network World. Archived from the original on May 29, 2012.
  10. ^ Al-Janabi, Sufyan T. Faraj; et al. (2012). "Combining Mediated and Identity-Based Cryptography for Securing Email". In Ariwa, Ezendu; et al. (eds.). Digital Enterprise and Information Systems: International Conference, Deis, [...] Proceedings. Springer. pp. 2–3.
  11. ^ "Mike Meyers CompTIA Security+ Certification Passport", by T. J. Samuelle, p. 137.
  12. ^ Henry, William (4 March 2016). "Trusted Third Party Service".
  13. ^ http://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html
  14. ^ "CA:Symantec Issues". Mozilla Wiki. Retrieved 10 January 2020.
  15. ^ "Chrome's Plan to Distrust Symantec Certificates". Google security blog. Retrieved 10 January 2020.
  16. ^ "JDK-8215012 : Release Note: Distrust TLS Server Certificates Anchored by Symantec Root CAs". Java Bug Database. Retrieved 10 January 2020.
  17. ^ 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.CS1 maint: archived copy as title (link)
  18. ^ Ed Gerck, Overview of Certification Systems: x.509, CA, PGP and SKIP, in The Black Hat Briefings '99, http://www.securitytechnet.com/resource/rsc-center/presentation/black/vegas99/certover.pdf and http://mcwg.org/mcg-mirror/cert.htm Archived 2008-09-05 at the Wayback Machine
  19. ^ "Decentralized Identifiers (DIDs)". World Wide Web Consortium. 9 December 2019. Archived from the original on 14 May 2020. Retrieved 16 June 2020.
  20. ^ "Decentralized Public Key Infrastructure" (PDF). weboftrust.info. 23 December 2015. Retrieved 23 June 2020.
  21. ^ Allen, Christopher (November 2015). "Decentralized Public Key Infrastructure" (PDF). Rebooting the Web of Trust design workshop.
  22. ^ Huang, Yahsin (2019-05-14). "Decentralized Public Key Infrastructure (DPKI): What is it and why does it matter?". Hacker Noon. Retrieved 2019-05-22.
  23. ^ Fromknecht, Conner (November 2014). "A Decentralized Public Key Infrastructure with Identity Retention" (PDF). IACR Cryptology ePrint Archive.
  24. ^ Bünz, Benedikt (February 2019). "FlyClient: Super-Light Clients for Cryptocurrencies" (PDF). IACR Cryptology ePrint Archive.
  25. ^ Letz, Dominic (May 2019). "BlockQuick: Super-Light Client Protocol for Blockchain Validation on Constrained Devices" (PDF). IACR Cryptology ePrint Archive.
  26. ^ Ellis J. H., January 1970,The Possibility of Secure Non-Secret Digital Encryption Archived 2014-10-30 at the Wayback Machine
  27. ^ Stephen Wilson, December 2005, "The importance of PKI today" Archived 2010-11-22 at the Wayback Machine, China Communications, Retrieved on 2010-12-13
  28. ^ Mark Gasson, Martin Meints, Kevin Warwick (2005), D3.2: A study on PKI and biometrics, FIDIS deliverable (3)2, July 2005
  29. ^ "xipki/xipki · GitHub". Github.com. Retrieved 2016-10-17.
  30. ^ Sullivan, Nick (10 July 2014). "Introducing CFSSL - Cloudflare's PKI toolkit". CloudFlare's Blog. CloudFlare. Retrieved 18 April 2018.
  31. ^ "cloudflare/cfssl · GitHub". Github.com. Retrieved 18 April 2018.
  32. ^ "hashicorp/vault · GitHub". Github.com. Retrieved 18 April 2018.
  33. ^ Should We Abandon Digital Certificates, Or Learn to Use Them Effectively?, Forbes magazine
  34. ^ HTTP/2 Frequently Asked Questions From Github HTTP/2 wiki
  35. ^ "Microsoft Security Advisory: Fraudulent Digital Certificates could allow spoofing". Microsoft. March 23, 2011. Retrieved 2011-03-24.

External links[edit]

Related Notes
Get a free MyMarkup account to save this article and view it later on any device.
Create account

End User License Agreement

Summary | 1 Annotation
Certificate authorities
2020/08/06 14:43