Multiple certificates must exist if for no other reason than to support the multiple identities most people have on the Internet: a Hotmail address for online purchases, an ISP address for friends and families, a professional association address for business networking and so on. Additionally, there's no reason to believe that these certificates should exist in just one trust community. Multiple trust anchors (a CA's root certificate at the head of a hierarchy or within a mesh community) or multiple trust lists (a collection of CA root certificates, defining a trusted community on a single platform) will be the norm. The challenge for certificate-storage vendors is to support this model and make it easy to use.
Three major challenges face digital-certificate usage: Managing the trust communities, managing the certificates and making a user feel as comfortable using certificates as he or she feels about using ordinary keys. None of these has been uniformly addressed. Instead, too many vendors providing certificate-enabled applications are striving for user simplicity by forcing the unrealistic single-certificate/single-trust community model, rather than grappling with the tougher issues.
Consider an environment where the Web browser and e-mail program can use only a single trust list and a company wants to use a special e-mail address and certificate for moving encrypted, confidential documents within the company. Further, it wants to prevent accidental, secure mailings to nonemployees. Because e-mail programs do not usually support advanced certificate extensions (such as name constraints, policies or Extended Key Usage), the only way to restrict secure mail is to delete all but the company's CA from the trusted-root certificate list. But doing this blocks any other secure e-mail usage and causes the Web browser to issue security warnings when used for external SSL connections.
Certificate support should be moving toward labeling of security communities (that is, some form of trust model) and associating them with the user certificates (one or many per community). For example, a business user could have a top-secret community for internal product development, a special extranet community for secure business and the general public community for public Web access. A home user could have banking, health and government communities, along with the general public community. At any time, he or she could be using one or all of his or her certificates and associated trust communities.
The prospect of simultaneous usage will impact the development of certificate storage and of trust lists or anchors (two methods for defining a trust community). Smartcard technology will afford limited flexibility in a multicertificate/multitrust environment. You either put everything on one card or get multiple readers to support many cards in use at once. "Everything on one card" runs counter to the standard credit-card advice of "multiple cards in multiple places." But multiple readers will be expensive to deploy. Meanwhile, hard-drive storage is less secure as well as lacking in portability. The most compelling option today is the USB token. USB hubs are appearing in keyboards and CRTs, making it relatively easy to use a number of USB tokens simultaneously.
Public key technology has a ways to go before it delivers a secure digital future. Although many tactical applications for it exist, we will continue to stumble on one issue or another until the PKI community develops a sound road map and moves forward on strategic solutions. Managing multiple identities and trust communities is just one more item on the list.
Robert Moskowitz is a senior technical director at ICSA. Send your comments on this column to him at rgm@htt-consult.com.