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
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning editorial writers on the latest customer relationship management (CRM)and call center technology issues today. Our goal is to keep you informed on the hottest issues facing this fast-changing industry.
Hannah Smalltree, Editorial Director
and complex, "you don't want to build a PKI system until you have at
least two applications" that can use it, says William Hugh Murray, an independent security
consultant in New Canaan, Conn. He also recommends making very clear the authorization and access
policies you'll be embedding in your PKI system. Traditional paper-based authorization systems
contain a lot of assumptions about who has what access and who can vouch for a user's identity, he
says. A PKI system will fail if it doesn't reflect the way such access policies are really
administered, he says.
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 rscheier@charter.net.
----------------------------------------------
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.
Secure
Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, Second
Edition
By Warwick Ford & Michael S. Baum
Publisher Name: Prentice Hall
Date published: Dec. 2000
Pages: 620
Cover Type: Soft Cover
Summary:
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