If you're even considering implementing public key infrastructure (PKI) to guard your networks, you know about the sad state of this technology. The cost and complexity has turned off so many customers that once high-flying vendors such as Baltimore Technologies plc are struggling for survival, and others, such as Xcert International Inc., are being gobbled up by larger players.
You know a technology is in trouble when you ask analysts for a list of the latest and greatest tools only to hear that there really aren't any great tools or that the problems with the technology go far beyond what any specific tool can solve.
PKI uses a combination of public and private "keys" to encrypt messages and to authenticate the identity of the person sending the messages. PKI implementations include digital certificates, which hold the public keys; a CA (certificate authority), which issues and validates the certificates; an RA (registration authority), which tells the CA whether to issue the certificate and one or more directories to hold the certificates. By accessing a public directory of certificates, the sender can use the recipient's public key to encrypt a message, but only the recipient can use their private key to decrypt it.
Sound complicated? It is. That's why you need to ask some basic questions before you even start looking at specific PKI tools. They include:
Is PKI right for my business?
Because PKI is so expensive
Do I have a global naming convention for my users?
Before you can start issuing digital certificates and keys, you need to know to whom you'll be issuing them. That's no simple feat in many organizations, where the same employee might have five or six aliases to access different systems. Before moving into PKI, says Murray, you need to agree on standard naming formats across your organization and then implement them so each user has only one, unique, uniformly accessible name by which the PKI system can identify them.
Do I have an LDAP-enabled directory?
Many large enterprises have, or are creating, enterprisewide directories using platforms such as Novell Inc.'s Novell Directory Services or Microsoft Corp.'s Active Directory. Creating such a directory is difficult and time-consuming, but is vital to a PKI implementation because it holds the central list of users whose access will be managed through PKI. It's vital, says Murray, to make sure your directory is LDAP (Lightweight Directory Access Protocol) enabled because LDAP is the prime method by which applications will communicate with the directory. The directory must also, he says, "be PKI-aware. It needs to know about certificates and keys and revocations (of certificates) and all those kinds of things."
How will my applications link to my PKI system?
PKI isn't much good if it can't talk to your applications. Having an LDAP and PKI-enabled directory is an essential foundation but doesn't solve the entire problem. Customers should ask their application vendors specific questions about how their applications will link to PKI systems, says Peter Lindstrom, senior security analyst at Hurwitz Group Inc.
For example, does the PKI vendor write directly to the APIs (application programming interfaces) of your most important applications? Or does the PKI system talk to the application through another layer, such as the operating system or an application server, which adds to the complexity and makes debugging more difficult? Does your application favor one vendor's CA over another, possibly changing your choice of PKI vendor? "The real critical piece," says Lindstrom, "is can I use a certificate within my application to authenticate or sign data or encrypt the data?"
The bottom line
There's no one "silver bullet" tool for creating and managing PKI. It's all about what PKI can do for your core application(s). You need to create a solid infrastructure which includes a single naming convention and LDAP-capable directory, make sure your PKI infrastructure corresponds to your business processes, and then ask your application and PKI vendors very specific questions about how they work together.
About the author
Robert L. Scheier is a former technology editor at Computerworld, now a freelance writer and editorial consultant in Boylston, Mass. He can be reached at firstname.lastname@example.org.
Talk back! Do you have any comments on this column? If so, share them in our Encryption Discussion Forum.
SearchSecurity's encryption experts have answered your most frequently asked questions. See if your question has already been answered, or submit it to our experts.
Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, Second
By Warwick Ford & Michael S. Baum
Publisher Name: Prentice Hall
Date published: Dec. 2000
Cover Type: Soft Cover
This book offers a complete blueprint showing companies how to implement state-of-the-art e-commerce, while minimizing all the security risks involved. This new edition has been completely updated to reflect today's latest developments in digital signatures, public-key infrastructure, EDI technical standards, certification and authentication.
This was first published in September 2001