Public Key Infrastructure (PKI) is a framework of technologies and policies designed to manage digital identities. On the Internet, we need digital identities to be able to safely communicate with one another. After all, what's the point of strong encryption if you're sending all your sensitive data to the wrong people! Being able to ascertain that you're talking to the intended recipient makes all the difference when it comes to confidentiality.

A long time ago, when I was just starting with cryptography and encountered PKI for the first time, I thought this term referred to key infrastructure that was public. An easy mistake to make if you're a beginner. Very quickly, of course, I learned about public keys, and that the name PKI refers to how they're being organised; PKIs are infrastructures of public keys.

A digital identity is encoded as a pair of connected keys in a particular cryptosystem. The private key is the identity and has to be kept secret; the public key, which is intrinsically connected to the private key, gives the general public means to validate the ownership of the private key.

PKIs don't necessarily need to use certificates, but the PKIs in dominant use today do. A certificate bundles a public key with some additional useful information. Every certificate will also include a signature from the issuing authority, further simplifying the validation process.

It's easy to think that a PKI is something that's defined in a technical specification somewhere. For example, when it comes to X.509 [the dominant standard for how PKIs are implemented], you may come across RFC 5280 and mistake it for a PKI. It's much more complicated than that. In order to build a PKI, we need a foundation of technical specifications, but these documents alone are insufficient. They merely establish a framework to build upon and define a universe of possibilities. A PKI comes to life at the cross-roads of when technical facilities meet the policies for how they're going to be used to achieve a purpose. Different goals may lead to different PKIs, all built on the same technical foundations. 

Most of us encounter our first PKI when we start to need a website certificate. For many, that remains the only PKI they ever work with. As you spend more time in this space, however, you realise that there is—again—more to it. On one end, anyone can use the same PKI principles to build their own private PKI to use internally, and a lot of people do.

On the other end, and perhaps more interestingly, you eventually realise that there is a plethora of public PKIs as well. The variety in PKI exists for technical reasons (different goals and requirements) as well as political and financial reasons (different entities wanting control). 

A public PKI is one that is created for many unrelated organisations and (possibly) individuals to participate in together. For example, the most popular and best-defined public PKI is run by major browser vendors; it's called Web PKI. If you need a certificate for your public website, your only choice is to get one from this PKI.

A public PKI is not defined by size. Web PKI is large and exists on one end of the spectrum. On the other end, a single (possibly larger) vendor could, for example, create a public PKI to use with their suppliers, and that's conceptually the same.

Let's take a look at some popular public PKIs you may encounter:

• Web PKI; this is the PKI we use every day, every single time we connect to a website somewhere. At a high level, there are four vendors that control this PKI: Apple, Firefox, Google, and Microsoft. CA/Browser Forum is the industry body that oversees the ecosystem, although some aspects of Web PKI are controlled directly by the browsers.
• Internet PKI is a close cousin of Web PKI. Back in the day, they were similar if not identical initially, but they diverged over the years. As one illustration, Web PKI mandates that all public certificates are logged for posterity, whereas Internet PKI doesn't, at least not at present. Sometimes these differences will matter and sometimes they will not. With the post-quantum migration under way, it's likely that the two PKIs will continue to diverge.
• Code signing PKIs vary in popularity and size. Notice the plural, as there isn't a single PKI used by everyone. The vendors who need it (for example, Apple, Google, and Microsoft) use different approaches to trust, and there is a small number of certificates issued. CA/Browser forum has specific technical requirements for code signing certificates. The first official release listed on their web site was from 2019, although there were earlier unofficial versions going back to 2016.
• S/MIME PKI is another small ecosystem that's still being shaped up. The first technical specification for S/MIME certificates was published in January 2023.
• BIMI (Brand Indicators for Message Identification) certificates are used by organisations who wish their logos to be associated with the emails they send, for branding reasons.  
• Matter PKI is a specialised PKI used by IoT devices, enabling the devices from a number of manufacturers to work together in different roles. You may increasingly rely on this PKI in your daily life, but you're unlikely to have to ever think about it for as long as you remain just a customer.

When it comes to public PKIs, most of the time you choose one based on your need. For example, if you're manufacturing Matter devices, the only PKI you will care about is Matter PKI. For Internet servers, Web PKI works most of the time. In some rare situations (you will know when you encounter them), you'll need to look at Internet PKI.