In the early days of the internet, one of the first functional problems users faced was how to verify that entities on the other end of a connection were who they said they were. At first, the nebulous nature of online transactions inhibited e-commerce, since buyers feared that their payment information might be hijacked. This lack of trust precipitated the development of digital certificates.

This was not a simple task. When someone places a telephone call, they direct it to a number they already know. They have a high level of confidence that they will be connected to only that number. The internet, at that point in time, offered no such assurances. Sites didn’t know who was doing the buying, and buyers didn’t know for sure that they were connected to a valid seller. Retailers and buyers needed a method to establish trust, or the potential of e-commerce would have been totally deflated.

Public Key Infrastructure

The framework for the answer came to be known as public key infrastructure (PKI). According to IBM, PKI is “a system of facilities, policies and services that supports the use of public key cryptography for authenticating the parties involved in a transaction.” It has the cryptographic public key system as its core, where a public key is mapped to a private key held by a user.

PKI includes a certificate authority (CA) that stores, issues and signs digital certificates. It is a repository for the certificates that can revoke them if they become invalid. The registration authority verifies the actual identities of the parties seeking to store their digital certificates with the CA.

A central directory — a secure location in which to store and index keys — is also part of the PKI, and is a necessary component for high-speed use. This ties into the certificate management system that controls access to stored certificates and delivers those that are to be issued.

A certificate policy dictates how all these components interrelate, including what happens when things fail. Perhaps a certificate needs to be uncertified, for example. That gave rise to a certificate revocation list (CRL), which is just what it sounds like: a public list of all the certificates that a CA has revoked. A browser can determine whether the certificate is included on this list and ignore it accordingly.

The use of certificates gave rise to Transport Layer Security (TLS) protocol, which enables encrypted communicated between two sites. TLS is invoked when HTTPS precedes a site’s URL.

Real-Life Revocations

Real life has a way of overhauling designs. Browsers did not always check CRLs or trust the results returned to them. CRLs are large and need to be refreshed constantly — almost with every transaction. This can give users the impression that the site’s response time is slow, even if it is not.

Another mechanism to deal with this problem, the Online Certificate Status Protocol (OCSP), prompted the browser to ask the issuing CA about a single certificate only. It would then return a response about that certificate’s validity, which took less time to parse than a CRL list.

But there was an implied problem here: The CA would be able to track what sites you were looking at based on OCSP requests. Worse, there was no binding contract present, so the organization would be free to sell that information to a third party without your consent.

Stapling and Certificate Transparency

Some developers thought that attaching the OCSP response to the certificate would fix this problem, since it would be there all the time and not yield a browser’s URL requests to a CA. But an attacker might not want this information to be attached to a certificate. That’s what the Must-Staple flag is for. When a certificate is requested from a CA, a user can require that stapling always be present. If that stapling is not present, the user can assume that the certificate has been revoked and the browser will reject it.

There’s another problem here: What if the CA has been breached or is functioning poorly and issuing rogue certificates? The solution was a CA requirement called certificate transparency, which will be mandatory in certain browsers next year. It is designed to notify a site operator if any certificates are issued for a domain under his or her care. It’s not perfect, but can help to sound the alarm if something goes wrong with the issuance process.

Re-Evaluating Digital Certificates

Revocation of existing certificates has become complex and indeterminate. Symantec, one of the earliest CAs, experienced a massive problem when Chrome moved to invalidate certificates issued by the company. Symantec’s application program interfaces (APIs) were thought to be at fault here, but the net result was the same: Trust was not assured through the use of a certificate.

The entire topic of certificates may need to be re-evaluated. Use cases have become complex and time-consuming. There is no true guarantee of trust, though certificates are a good first step. The internet at large will have to come to terms with how certificates are used and issued in the real world to determine whether the benefits outweigh the risks.