View source for Public key infrastructure

{{Short description|System that can issue, distribute and verify digital certificates}}
[[File:Public-Key-Infrastructure.svg|thumb|300px|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 [[public key certificate|digital certificate]]s and manage [[public-key cryptography|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 key]]s with respective identities of entities (like people and organizations).<ref>
{{cite journal 
  |last=Chien 
  |first=Hung-Yu 
  |date=2021-08-19 
  |title=Dynamic Public Key Certificates with Forward Secrecy 
  |journal=Electronics 
  |language=en 
  |volume=10 
  |issue=16 
  |pages=2009 
  |doi=10.3390/electronics10162009 
  |issn=2079-9292
  |doi-access=free
}}
</ref><ref>{{cite web 
  |access-date=14 May 2024 
  |language=en 
  |publisher=European Union 
  |title=Public Key Infrastructure (PKI) 
  |url=https://www.enisa.europa.eu/topics/incident-response/glossary/public-key-infrastructure-pki 
  |website=The European Union Agency for Cybersecurity (ENISA) :: Incident Response :: Glossary 
  |archive-date=14 May 2024 
  |archive-url=https://web.archive.org/web/20240514031836/https://www.enisa.europa.eu/topics/incident-response/glossary/public-key-infrastructure-pki 
  |url-status=dead 
  }}</ref> 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. When done over a network, this requires using a secure certificate enrollment or certificate management protocol such as [[Certificate Management Protocol|CMP]].

The PKI role that may be delegated by a CA to assure 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.<ref name="techotopia">{{cite web|last=Fruhlinger|first=Josh|date=29 May 2020|title=What is PKI? And how it secures just about everything online|url=https://www.csoonline.com/article/3400836/what-is-pki-and-how-it-secures-just-about-everything-online.html|access-date=26 August 2021|website=CSOOnline|archive-date=27 August 2021|archive-url=https://web.archive.org/web/20210827042001/https://www.csoonline.com/article/3400836/what-is-pki-and-how-it-secures-just-about-everything-online.html|url-status=live}}</ref> 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)."<ref name="IETF 3647">{{cite web|title=Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework|url=https://www.ietf.org/rfc/rfc3647.txt|website=IETF|access-date=26 August 2020|archive-date=23 July 2020|archive-url=https://web.archive.org/web/20200723225652/https://www.ietf.org/rfc/rfc3647.txt|url-status=live}}</ref> While [[Microsoft]] may have referred to a subordinate CA as an RA,<ref name="msdn">{{cite web|title=Public Key Infrastructure|url=https://msdn.microsoft.com/en-us/library/windows/desktop/bb427432%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396|website=MSDN|access-date=26 March 2015|archive-date=2 July 2017|archive-url=https://web.archive.org/web/20170702065709/https://msdn.microsoft.com/en-us/library/windows/desktop/bb427432%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396|url-status=live}}</ref> 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 that 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 associated 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 certificate]]s.<ref>{{cite web|url=https://www.ssltrust.com.au/help/setup-guides/client-certificate-authentication|title=Using Client-Certificate based authentication with NGINX on Ubuntu - SSLTrust|website=SSLTrust|access-date=13 June 2019|archive-date=26 August 2019|archive-url=https://web.archive.org/web/20190826005346/https://www.ssltrust.com.au/help/setup-guides/client-certificate-authentication|url-status=live}}</ref>

== Capabilities ==

PKI provides "trust services" - in plain terms trusting the actions or outputs of entities, be they people or computers. Trust service objectives respect one or more of the following capabilities: Confidentiality, Integrity and Authenticity (CIA).

'''Confidentiality:''' Assurance that no entity can maliciously or unwittingly view a payload in clear text. Data is encrypted to make it secret, such that even if it was read, it appears as gibberish.  Perhaps the most common use of PKI for confidentiality purposes is in the context of Transport Layer Security ([[Transport Layer Security|TLS]]).  TLS is a capability underpinning the security of data in transit, i.e. during transmission. A classic example of TLS for confidentiality is when using a web browser to log on to a service hosted on an internet based web site by entering a password.

'''Integrity:''' Assurance that if an entity changed (tampered) with transmitted data in the slightest way, it would be obvious it happened as its integrity would have been compromised.  Often it is not of utmost importance to prevent the integrity being compromised (tamper proof), however, it is of utmost importance that if integrity is compromised there is clear evidence of it having done so (tamper evident).

'''Authenticity:''' Assurance that an entity has: i) certainty of what it's connecting to; and / or ii) can evidence its own legitimacy when connecting to a protected service. The former is labelled as server certificate authentication, typically employed when logging on at a web server. The latter is designated as client certificate authentication, for instance used when logging on with a smart card hosting a digital certificate and private key.

== Design ==

[[Public-key cryptography]] is a [[cryptographic]] technique that enables entities to [[secure communication|securely communicate]] on an insecure public network, and reliably verify the identity of an entity via [[digital signatures]].<ref>{{cite book|author=Adams, Carlisle |author2=Lloyd, Steve|title=Understanding PKI: concepts, standards, and deployment considerations|publisher=Addison-Wesley Professional|year=2003|isbn=978-0-672-32391-1|pages=11–15|url=https://books.google.com/books?id=ERSfUmmthMYC&pg=PA11}}</ref>

A public key infrastructure (PKI) is a system for the creation, storage, and distribution of [[public key certificate|digital certificate]]s, which are used to verify that a particular public key belongs to a certain entity. The PKI creates digital certificates that map public keys to entities, securely stores these certificates in a central repository and revokes them if needed.<ref>{{cite book|author=Trček, Denis|title=Managing information systems security and privacy|publisher=Birkhauser|year=2006|isbn=978-3-540-28103-0|page=69|url=https://books.google.com/books?id=oswvyhAftLsC&pg=PA69}}</ref><ref name="Vacca-2004-p8">{{cite book|author=Vacca, Jhn R.|title=Public key infrastructure: building trusted applications and Web services|publisher=CRC Press|year=2004|isbn=978-0-8493-0822-2|page=8|url=https://books.google.com/books?id=3kS8XDALWWYC&pg=PA8}}</ref><ref>{{cite book|author=Viega, John|title=Network Security with OpenSSL|publisher=O'Reilly Media|year=2002|isbn=978-0-596-00270-1|pages=61–62|display-authors=etal}}</ref>

A PKI consists of:<ref name="Vacca-2004-p8" /><ref name="ABCs-of-PKI">{{cite news|author=McKinley, Barton|title=The ABCs of PKI: Decrypting the complex task of setting up a public key infrastructure|work=Network World|date=January 17, 2001|url=http://www.networkworld.com/research/2000/0117feat.html|url-status=dead|archive-url=https://web.archive.org/web/20120529211639/http://www.networkworld.com/research/2000/0117feat.html|archive-date=May 29, 2012}}</ref><ref>{{cite book|author=Al-Janabi, Sufyan T. Faraj|chapter=Combining Mediated and Identity-Based Cryptography for Securing Email|editor=Ariwa, Ezendu |display-editors=etal |title=Digital Enterprise and Information Systems: International Conference, Deis, <nowiki>[...]</nowiki> Proceedings|publisher=Springer|year=2012|isbn=9783642226021|pages=2–3|chapter-url=https://books.google.com/books?id=s-HVzAc_ZqEC&pg=PA2|display-authors=etal}}</ref>

* A ''[[certificate authority]]'' (CA), which 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'', a secure location in which keys are stored and indexed;
* A ''certificate management system'', which manages things like the access to stored certificates or the delivery of the certificates to be issued;
* A ''[[certificate policy]]'', which states the PKI's requirements concerning its procedures. Its purpose is to allow outsiders to analyze the PKI's trustworthiness.

== Methods of certification ==

=== Certificate authorities ===
{{main|Certificate authority}}

The primary role of the CA is to [[digital signature|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.<ref>"Mike Meyers CompTIA Security+ Certification Passport", by T. J. Samuelle, p. 137.</ref> 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.<ref>
{{cite web
 |url = http://www.businessdictionary.com/definition/Trusted-Third-Party-Services-TTP-Services.html
 |title = Trusted Third Party Service
 |date = 4 March 2016
 |first = William
 |last = Henry
 |access-date = 4 March 2016
 |archive-date = 4 March 2016
 |archive-url = https://web.archive.org/web/20160304211542/http://www.businessdictionary.com/definition/Trusted-Third-Party-Services-TTP-Services.html
 |url-status = dead
 }}</ref>

==== Certificate revocation ====
{{main|Certificate revocation}}
A certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker would be able to exploit such a compromised or mis-issued certificate until expiry.{{sfn|Smith|Dickinson|Seamons|2020|p=1}} Hence, revocation is an important part of a public key infrastructure.{{sfn|Sheffer|Saint-Andre|Fossati|2022|loc=7.5. Certificate Revocation}} Revocation is performed by the issuing [[certificate authority]], which produces a [[cryptographically authenticated]] statement of revocation.{{sfn|Chung|Lok|Chandrasekaran|Choffnes|2018|p=3}}

For distributing revocation information to clients, timeliness of the discovery of revocation (and hence the window for an attacker to exploit a compromised certificate) trades off against resource usage in querying revocation statuses and privacy concerns.{{sfn|Smith|Dickinson|Seamons|2020|p=10}} If revocation information is unavailable (either due to accident or an attack), clients must decide whether to ''fail-hard'' and treat a certificate as if it is revoked (and so degrade [[availability]]) or to ''fail-soft'' and treat it as unrevoked (and allow attackers to sidestep revocation).{{sfn|Larisch|Choffnes|Levin|Maggs|2017|p=542}}

Due to the cost of revocation checks and the availability impact from potentially-unreliable remote services, [[Web browsers]] limit the revocation checks they will perform, and will fail-soft where they do.{{sfn|Smith|Dickinson|Seamons|2020|p=1-2}} [[Certificate revocation lists]] are too bandwidth-costly for routine use, and the [[Online Certificate Status Protocol]] presents connection latency and privacy issues. Other schemes have been proposed but have not yet been successfully deployed to enable fail-hard checking.{{sfn|Sheffer|Saint-Andre|Fossati|2022|loc=7.5. Certificate Revocation}}

==== 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 report from 2015,<ref>{{cite web|url=http://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html|title=Counting SSL certificates|date=13 May 2015|access-date=13 May 2015|archive-date=16 May 2015|archive-url=https://web.archive.org/web/20150516035536/http://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html|url-status=live}}</ref> 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 ([[NortonLifeLock|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 major issues in how certificate issuing was managed, all major players gradually distrusted Symantec-issued certificates, starting in 2017 and completed in 2021.<ref>{{cite web |title=CA:Symantec Issues |url=https://wiki.mozilla.org/CA:Symantec_Issues |website=Mozilla Wiki |access-date=10 January 2020 |ref=symantec-mozilla |archive-date=8 December 2019 |archive-url=https://web.archive.org/web/20191208002916/https://wiki.mozilla.org/CA%3ASymantec_Issues |url-status=live }}</ref><ref>{{cite web |title=Chrome's Plan to Distrust Symantec Certificates |url=https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html |website=Google security blog |access-date=10 January 2020 |ref=symantec-chrome |archive-date=9 October 2023 |archive-url=https://web.archive.org/web/20231009063828/https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html |url-status=live }}</ref><ref>{{cite web |title=JDK-8215012 : Release Note: Distrust TLS Server Certificates Anchored by Symantec Root CAs |url=https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215012 |website=Java Bug Database |access-date=10 January 2020 |ref=symantec-java |archive-date=1 March 2021 |archive-url=https://web.archive.org/web/20210301134940/https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215012 |url-status=live }}</ref><ref>{{cite web |date=2023-09-05 |title=Information about distrusting Symantec certificate authorities |url=https://support.apple.com/en-us/HT208860 |access-date=2024-01-16 |website=Apple Support |language=en |archive-date=2024-01-16 |archive-url=https://web.archive.org/web/20240116203210/https://support.apple.com/en-us/HT208860 |url-status=live }}</ref>

==== 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.<ref>Single Sign-On Technology for SAP Enterprises: What does SAP have to say? {{cite web |url=http://www.secude.com/html/?id=1890 |title=Single Sign-On Technology for SAP Enterprises: What does SAP have to say? &#124; May 2010 &#124; SECUDE AG |access-date=2010-05-25 |url-status=dead |archive-url=https://web.archive.org/web/20110716031415/http://www.secude.com/html/?id=1890 |archive-date=2011-07-16 }}</ref>

Starting Sep 2020, TLS Certificate Validity reduced to 13 Months.

=== Web of trust ===
{{Main|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 [[public key certificate|certificate]]s 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 [[Pretty Good Privacy|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 [[Pretty Good Privacy|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 trustworthiness of that enterprise's or domain's implementation of PKI.<ref name="Overview">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 {{Webarchive|url=https://web.archive.org/web/20070926205229/http://www.securitytechnet.com/resource/rsc-center/presentation/black/vegas99/certover.pdf |date=2007-09-26 }} and http://mcwg.org/mcg-mirror/cert.htm {{Webarchive|url=https://web.archive.org/web/20080905230841/http://mcwg.org/mcg-mirror/cert.htm |date=2008-09-05 }}</ref>

The web of trust concept was first put forth by PGP creator [[Phil Zimmermann]] in 1992 in the manual for PGP version 2.0:

{{ quote
| 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 ===
{{main|Simple public-key infrastructure}}

Another alternative, which does not deal with public authentication of public key information, is the simple public key infrastructure (SPKI), which grew out of three independent efforts to overcome the complexities of [[X.509]] and [[Pretty Good Privacy|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.<ref>{{cite web |last=Gonzalez |first=Eloi |title=Simple Public Key Infrastructure |url=https://www.limited-entropy.com/docs/spki.pdf |access-date=2022-05-02 |archive-date=2022-10-06 |archive-url=https://web.archive.org/web/20221006091606/https://www.limited-entropy.com/docs/spki.pdf |url-status=dead }}</ref> 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 gap (networking)|air-gapped]] network in an office.

=== Decentralized PKI ===

[[Decentralized identifiers]] (DIDs) eliminate 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).<ref name="ec">{{cite web |title=Decentralized Identifiers (DIDs) |url=https://www.w3.org/TR/2019/WD-did-core-20191209/ |archive-url=https://web.archive.org/web/20200514014423/https://www.w3.org/TR/2019/WD-did-core-20191209/ |website=[[World Wide Web Consortium]] |archive-date=14 May 2020 |date=9 December 2019 |access-date=16 June 2020 |quote=""}}</ref><ref name="dpki">{{cite web |title=Decentralized Public Key Infrastructure |url=https://www.weboftrust.info/papers/#pki |website=weboftrust.info |date=23 December 2015 |access-date=23 June 2020 |quote="" |archive-date=10 August 2022 |archive-url=https://web.archive.org/web/20220810022026/https://www.weboftrust.info/papers/#pki |url-status=live }}</ref>

== History ==
{{Unreferenced section|date=January 2014}}

Developments in PKI occurred in the early 1970s at the British intelligence agency [[GCHQ]], where [[James H. Ellis|James Ellis]], [[Clifford Cocks]] and others made important discoveries related to encryption algorithms and key distribution.<ref>{{cite web |last=Ellis |first=James H. |author-link=James H. Ellis |date=January 1970 |url=http://cryptocellar.web.cern.ch/cryptocellar/cesg/possnse.pdf |title=The Possibility of Secure Non-Secret Digital Encryption |archive-url=https://web.archive.org/web/20141030210530/https://cryptocellar.web.cern.ch/cryptocellar/cesg/possnse.pdf |archive-date=2014-10-30}}</ref> 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 algorithm]]s in 1976 by [[Whitfield Diffie|Diffie]], [[Martin Hellman|Hellman]], [[Ron Rivest|Rivest]], [[Adi Shamir|Shamir]], and [[Leonard Adleman|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 primitive]]s 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 browser]]s) were sufficient. [[Taher Elgamal]] and others at [[Netscape Communications Corporation|Netscape]] developed the [[Transport Layer Security|SSL]] protocol ('[[HTTPS|https]]' in Web [[Uniform Resource Locator|URL]]s); it included key establishment, server authentication (prior to v3, one-way only), and so on.<ref>{{cite web |last=Prodromou |first=Agathoklis |date=2019-03-31 |title=TLS Security 2: A Brief History of SSL/TLS |url=https://www.acunetix.com/blog/articles/history-of-tls-ssl-part-2/ |access-date=2024-05-25 |website=Acunetix |language=en-US |archive-date=2024-05-25 |archive-url=https://web.archive.org/web/20240525143708/https://www.acunetix.com/blog/articles/history-of-tls-ssl-part-2/ |url-status=live }}</ref> 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.<ref>{{cite journal |date=2001 |title=PKI Assessment Guidelines |url=https://theworld.com/~goldberg/pagv30.pdf#page=43 |journal=[[Information Security Committee]] |volume=0 |issue=3 |pages=43 |archive-date=2024-05-25 |access-date=2024-05-25 |archive-url=https://web.archive.org/web/20240525143701/https://theworld.com/~goldberg/pagv30.pdf#page=43 |url-status=live }}</ref>

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.<ref>Stephen Wilson, December 2005, [http://www.china-cic.org.cn/english/digital%20library/200512/3.pdf "The importance of PKI today"] {{webarchive|url=https://web.archive.org/web/20101122134646/http://www.china-cic.org.cn/english/digital%20library/200512/3.pdf |date=2010-11-22 }}, ''China Communications'', Retrieved on 2010-12-13</ref> 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 Card]]s 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 [[Secure Sockets Layer|SSL/TLS]]). 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 [[Secure Sockets Layer|SSL/TLS]]. 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;<ref>Mark Gasson, Martin Meints, Kevin Warwick (2005), [http://www.fidis.net/resources/deliverables/hightechid/#c1785 D3.2: A study on PKI and biometrics] {{Webarchive|url=https://web.archive.org/web/20161007222349/http://www.fidis.net/resources/deliverables/hightechid/#c1785 |date=2016-10-07 }}, FIDIS deliverable (3)2, July 2005</ref>
* [[Internet of things]] requires secure communication between mutually trusted devices. A public key infrastructure enables devices to obtain and renew X.509 certificates, which are used to establish trust between devices and encrypt communications using [[Transport Layer Security|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 Software License|Apache licensed]])
* [[EJBCA]] is a full-featured, enterprise-grade, CA implementation developed in [[Java (programming language)|Java]]. It can be used to set up a CA both for internal use and as a service. ([[LGPL|LGPL licensed]])
* XiPKI,<ref>{{cite web |url=https://github.com/xipki/xipki |title=xipki/xipki · GitHub |publisher=Github.com |access-date=2016-10-17 |archive-date=2017-08-31 |archive-url=https://web.archive.org/web/20170831004530/https://github.com/xipki/xipki |url-status=live }}</ref> CA and OCSP responder. With [[SHA-3]] support, implemented in [[Java (programming language)|Java]]. ([[Apache Software License|Apache licensed]])
* XCA<ref>{{cite web |last=Hohnstädt |first=Christian |title=X - Certificate and Key management |url=https://hohnstaedt.de/xca/ |access-date=2023-12-29 |website=hohnstaedt.de |archive-date=2023-12-30 |archive-url=https://web.archive.org/web/20231230014137/https://www.hohnstaedt.de/xca/ |url-status=live }}</ref> is a graphical interface, and database. XCA uses OpenSSL for the underlying PKI operations.
* DogTag is a full featured CA developed and maintained as part of the [[Fedora Project]].
* CFSSL<ref>{{cite web|url=https://blog.cloudflare.com/introducing-cfssl/|title=Introducing CFSSL - Cloudflare's PKI toolkit|publisher=CloudFlare|website=CloudFlare's Blog|last=Sullivan|first=Nick|date=10 July 2014|access-date=18 April 2018}}</ref><ref>{{cite web|url=https://github.com/cloudflare/cfssl|title=cloudflare/cfssl · GitHub|publisher=Github.com|access-date=18 April 2018|archive-date=8 March 2018|archive-url=https://web.archive.org/web/20180308060815/https://github.com/cloudflare/cfssl|url-status=live}}</ref> open source toolkit developed by [[CloudFlare]] for signing, verifying, and bundling TLS certificates. ([[BSD licenses#2-clause|BSD 2-clause licensed]])
* Vault<ref>{{cite web|url=https://github.com/hashicorp/vault|title=hashicorp/vault · GitHub|publisher=Github.com|access-date=18 April 2018|archive-date=11 June 2018|archive-url=https://web.archive.org/web/20180611024343/https://github.com/hashicorp/vault|url-status=live}}</ref> tool for securely managing secrets (TLS certificates included) developed by [[HashiCorp]]. ([[Mozilla Public License|Mozilla Public License 2.0 licensed]])
* Boulder, an [[Automated Certificate Management Environment|ACME]]-based CA written in [[Go (programming language)|Go]]. Boulder is the software that runs [[Let's Encrypt]].

== Criticism ==
{{see also|X.509#Security|Comodo Group#2011 breach incident|Diginotar#Issuance of fraudulent certificates}}
Some argue that purchasing certificates for securing websites by [[Transport Layer Security|SSL/TLS]] and securing software by [[code signing]] is a costly venture for small businesses.<ref>{{cite web |url=https://www.forbes.com/sites/richardstiennon/2013/05/14/should-we-abandon-digital-certificates-or-learn-to-use-them-effectively |title=Should We Abandon Digital Certificates, Or Learn to Use Them Effectively? |work=[[Forbes]] |access-date=2017-09-10 |archive-date=2016-12-23 |archive-url=https://web.archive.org/web/20161223140432/http://www.forbes.com/sites/richardstiennon/2013/05/14/should-we-abandon-digital-certificates-or-learn-to-use-them-effectively/ |url-status=live }}</ref>  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 [[Transport Layer Security|TLS]] connection.<ref>{{cite web |url=https://http2.github.io/faq/ |title=HTTP/2 Frequently Asked Questions |via=Github |work=HTTP/2 wiki |access-date=2015-09-17 |archive-date=2014-09-27 |archive-url=https://web.archive.org/web/20140927004541/http://http2.github.io/faq/ |url-status=live }}</ref> Web browser implementation of HTTP/2 including [[Google Chrome|Chrome]], [[Firefox]], [[Opera (web browser)|Opera]], and [[Microsoft Edge|Edge]] supports HTTP/2 only over TLS by using the [[ALPN]] extension of the TLS protocol. This would mean that, to get the speed benefits of HTTP/2, website owners would be forced to purchase SSL/TLS certificates controlled by corporations.

Currently the majority of web browsers are shipped with pre-installed [[Public key certificate#Intermediate certificate|intermediate certificates]] issued and signed by a certificate authority, by public keys certified by so-called [[root certificates]]. This means browsers need to carry a large number of different certificate providers, increasing the risk of a key compromise.<ref>{{cite web |title=Root Certificate vs Intermediate Certificates |url=https://aboutssl.org/root-certificates-vs-intermediate-certificates/ |access-date=2022-05-02 |website=About SSL |language=en-US |archive-date=2022-05-28 |archive-url=https://web.archive.org/web/20220528165904/https://aboutssl.org/root-certificates-vs-intermediate-certificates/ |url-status=live }}</ref>

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.<ref>{{cite web |work=Microsoft Security Advisory |title=Fraudulent Digital Certificates could allow spoofing |url=http://support.microsoft.com/kb/2524375 |date=March 23, 2011 |access-date=2011-03-24 |publisher=Microsoft |archive-date=2011-03-25 |archive-url=https://web.archive.org/web/20110325024402/http://support.microsoft.com/kb/2524375 |url-status=live }}</ref>

== See also ==
* [[Cryptographic agility]] (crypto-agility)
* [[Certificate Management Protocol]] (CMP)
* [[Certificate Management over CMS]] (CMC)
* [[Simple Certificate Enrollment Protocol]] (SCEP)
* [[Enrollment over Secure Transport]] (EST)
* [[Automatic Certificate Management Environment]] (ACME)
* [[Resource Public Key Infrastructure]] (RPKI)

== References ==

{{reflist}}

== Works cited ==

* {{cite book | doi = 10.1145/3278532.3278543 | chapter-url = https://taejoong.github.io/pubs/publications/chung-2018-ocsp.pdf | chapter = Is the Web Ready for OCSP Must-Staple? | title = Proceedings of the Internet Measurement Conference 2018 | year = 2018 | last1 = Chung | first1 = Taejoong | last2 = Lok | first2 = Jay | last3 = Chandrasekaran | first3 = Balakrishnan | last4 = Choffnes | first4 = David | last5 = Levin | first5 = Dave | last6 = Maggs | first6 = Bruce M. | last7 = Mislove | first7 = Alan | last8 = Rula | first8 = John | last9 = Sullivan | first9 = Nick | last10 = Wilson | first10 = Christo | pages = 105–118 | isbn = 9781450356190 | s2cid = 53223350 }}
* {{cite book | doi = 10.1109/sp.2017.17 | doi-access = free | chapter = CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers | title = 2017 IEEE Symposium on Security and Privacy (SP) | year = 2017 | last1 = Larisch | first1 = James | last2 = Choffnes | first2 = David | last3 = Levin | first3 = Dave | last4 = Maggs | first4 = Bruce M. | last5 = Mislove | first5 = Alan | last6 = Wilson | first6 = Christo | pages = 539–556 | isbn = 978-1-5090-5533-3 | s2cid = 3926509 }}
* {{cite ietf | rfc = 9325 | last1 = Sheffer | first1 = Yaron | last2 = Saint-Andre | first2 = Pierre | last3 = Fossati | first3 = Thomas | date = November 2022 | title = Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) }}
* {{cite book | doi = 10.14722/ndss.2020.24084 | doi-access = free | chapter = Let's Revoke: Scalable Global Certificate Revocation | title = Proceedings 2020 Network and Distributed System Security Symposium | year = 2020 | last1 = Smith | first1 = Trevor | last2 = Dickinson | first2 = Luke | last3 = Seamons | first3 = Kent | isbn = 978-1-891562-61-7 | s2cid = 211268930 }}

== Further reading ==

* {{cite book |last1=Choudhury |first1=Suranjan |title=Public key infrastructure: implementation and design |last2=Bhatnagar |first2=Kartik |last3=Haque |first3=Wasim |date=2002 |publisher=M&T Books |isbn=978-0-7645-4879-6 |series=Professional mindware |location=New York, NY}}
* {{cite book |last1=Schmeh |first1=Klaus |title=Cryptography and public key infrastructure on the Internet |date=2003 |publisher=Wiley |location=Chichester, West Sussex, England |isbn=0-470-84745-X}}

== External links ==
* [//w3techs.com/technologies/history_overview/ssl_certificate Market share trends for SSL certificate authorities] (W3Techs)

{{Cryptography navbox | public-key}}
{{SSL/TLS}}

{{Authority control }}

[[Category:Public key infrastructure| ]]
[[Category:Public-key cryptography]]
[[Category:Key management]]
[[Category:IT infrastructure]]
[[Category:Transport Layer Security]]