Editing Public key infrastructure (section)

== 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 }}</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}}</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}}</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}}</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}}</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 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}}</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=""}}</ref>