An alternative to PKI
By now, everyone has probably heard that encryption can be difficult and expensive. It may deserve this reputation. “Why Johnny Can’t Encrypt” and “Why Johnny Still Can’t Encrypt” showed that users have problems with using some public-key systems. Usability has gotten much better, and if these studies were done today with most successful e-mail encryption products, the results would probably be much more encouraging. On the other hand, there are still complexities that seem to make some public-key technologies unnecessarily complicated. You could see at this year’s RSA show.
The RSA Data Security Conference is one of the biggest gatherings of information security professionals in the industry and it’s where new products are often announced for the first time. This year’s show took place April 7-11 in San Francisco, and featured some interesting products and services. Some of these, however, should have made attendees raise an eyebrow or scratch their head as they pondered exactly why such new things were even needed. In particular, more than one vendor was demonstrating a path validation service for digital certificates. That’s right – they expect to be able to charge for this service and make money. If you’re one of those few remaining people who believe that using certificates is feasible for more than SSL, this might be enough to make you change your mind.
Digital certificates provide the basis for useful things like authentication, digital signatures and encryption, but the public-key infrastructure (PKI) that’s needed to create and manage them has a nasty reputation for being too difficult for users to actually use and for being extremely expensive to support. The fact that people feel that there’s a viable business in handling certificate processing seems to indicate that the technology is also getting far too complicated to be useful.
Because the thorough verification of an identity that’s done when certificates are created can be expensive, it’s typically not done very often, so that a certificate is typically valid for quite a while. A one-year or more lifetime for a certificate is typical. But because they’re valid for so long, you don’t know that a certificate is still valid when you go to use it. The corresponding private key could have been compromised. Or the user’s identity could have changed. Because the identities in certificates are based on X.500 names that include organizational structure, changing departments in an organization can also make the identity in a certificate invalid. Or the user could just no longer be part of the organization that issued the certificate.
Validating a certificate can be done by a call to an on-line certificate status protocol (OCSP) server, for example. You make an on-line call to an OCSP server and it tells you whether or not the certificate that you want to use is valid or not. More advanced protocols like the server-based certificate validation protocol (SCVP) can even answer more complicated questions, perhaps even determining if a certificate was valid when it was used instead of just determining if it’s currently valid. This is a tricky problem, and solving it requires being able to reconstruct the state of a certificate at times in the past.
Another difficult problem is caused by the complicated architectures that users of PKI are trying to implement. In particular, the bridged architectures in which every root certificate authority (CA) cross-certifies with a central bridge CA, makes it very difficult to trace a path up to a trusted root certificate. You can think of trust relationships between CAs as defining a directed graph, and deciding whether or not to trust a particular certificate requires determining whether or not a path in this directed graph exists between a certain set of points on the graph. This is a problem that can be hard to solve, so using certificates that come from more complex architectures can be tricky. So tricky that it’s apparently now better to rely on someone else to solve it that to do it yourself. That’s what the products at this year’s RSA show seem to tell us.
So with cutting-edge PKI technology, users need to make at least a few calls to servers. They might need to retrieve a certificate from an LDAP directory. Once they have a certificate, they need to check it’s validity by making another OCSP or SCVP call. And now it looks like a third call may be needed because it’s getting complicated to find a path from a user’s certificate to a trusted root CA. With all of these calls to servers going on, it makes you wonder if it wouldn’t just be simpler to make a single call to a server that asks for a symmetric key. That sounds like an alternative that’s better than what the state-of-the-art in PKI offers.