Network Computingwww.networkcomputing.com

Related Links

Preparing for Networking in the Next Millennium, November 15, 1998 EDI to E-commerce: Two Generations of Spending, December 15, 1998 Are Biometrics Too Good?, January 25, 1999 The Need for Host Authentication, February 22, 1999 DES Is Dead. Long Live...Well, Um, What?, March 22, 1999

Other Columnists this issue

Net Results By Dave Molta On the Edge By Art Wittmann

Company Directory

Browse our directory to get data, starting with a particular company.

Reader Service

Allows you to request additional product information from our advertisers.

Print The Full Article

ClickHere

E-mail this URL

ClickHere

Buy the Book

		our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

Digital certificate applications have been relegated to enclaves of users where the purpose and liabilities associated with the certificates are made clear by membership in the enclave. This approach to certificate usage has led to a user environment of multiple identities, similar to the very multiple login environment that digital certificates promised to improve. It's clear with the advent of PKCS-12 (www.Arsa.com/rsalabs/pubs/PKCS/html/pkcs-12.html) that multiple certificates are considered the norm, not the exception. Although I agree that it will be rare for one "person" (carbon- or silicon-based) to get by with only one certificate, it's important to work toward minimizing certificate proliferation. This requires tagging a certificate regarding its purpose and liabilities associated with its use. X.509 affords numerous ways to accomplish this, but a number of issues and processes need to come together to make it happen.

Tag, You're It An X.509 certificate is a collection of mandatory and optional data fields (see RFC 2459). No mandatory field influences the use of a certificate. The most commonly used optional field for influencing certificate usage is keyUsage. Some of the other optional fields that could control usage of certificate include extendedKeyUsages, certificatePolicies and nameConstraints. There are plans to use all of these fields, but there is no consistency among the various communities, leaving software vendors in a quandary over what to implement. There is even disagreement over the use of keyUsage: Should only the required bits be set, or at least the required bits?

Settings for any of these tags are the result of a joint decision by the certificate users and issuers. The users define what a certificate's purpose is in their business, and the issuers define what liability they are willing to assume for certificate usage. When the user community is tightly controlled, such as employees of a company, and the issuer has a stake in the community, the goals of the two groups tend to mesh. However, when the community is loosely bound, as in an industry group, and the certificate issuer is a third party, certificate tagging may be difficult. The more specific the limitation on certificate use, the greater the risk of misuse and misrepresentation, which tends to result in higher liability risks for the issuers. And the more general the certificate designation, the less potentially valuable those certificates are to the users.

The Canadian government has taken the position that keyUsage and the assurance of certificate and private key ownership are the only tags that can reasonably be enforced in a national PKI. To this end, Canada has specified four assurance levels: rudimentary, basic, medium and high. Furthermore, Canada has developed Certificate Policies (CPs) that define these levels, and any certificate issuer can develop a Certificate Practice Statement (CPS) implementing one or more of these CPs and be accredited to issue certificates accordingly. Then a user group can choose which CP meets its business requirements and work with issuers accredited for that CP.

Turning Dials A number of other user communities want more than what Canada is offering to control certificate usage. There are several CPs defined by various U.S. government agencies. The automobile industry has one CP solely for IPSec (IP Security) certificates, and it is developing different CPs for EDI systems and general end users. Various financial services companies also have their own CPs. While this abundance of CPs helps enforce particular community rules and limits liabilities, it also may be creating artificial barriers to certificate deployment.

Multiple CPs will result in certificate proliferation, or contractually involved cross-certification with policy mapping, or user management of acceptable Certificate Policy OIDs (Object Identifiers). Each of these alternatives may be more expensive than the simpler Canadian model.

As I mentioned earlier, the application arena is gearing up for multiple certificates. PKCS-12 seems to be emerging as the certificate container of choice. Of course, software management of certificates and user management of certificate usage are two different things. Consider how you decide what method of payment to use for a purchase: cash, check or a particular bank card. A user confronted with a certificate request has to make a similar decision when he or she has multiple certificates. The user needs to know which one to use and get it out of the wallet. Grabbing the wrong one can result in a failed transaction, or even an improperly billed or illegal transaction. We already know that having just one certificate is a pipe dream. There will always be a signing and an encrypting certificate. But the specter of dozens of certificates is intimidating.

PKIs will cross-certify, so that identity assignment costs can be contained and the number of certificates required for business can be controlled. However, there are many approaches to cross-certification. One of the more enticing is to map policy rules in the cross-certification. To applications that are performing policy validity checking, policy mapping means that the mapped policy is as valid as the original policy. However, there has been little real-world policy mapping. Many lawyers advise that policy mapping can only be done when the policies are legally equivalent. Purchasing agents have countered that they need only be significantly equivalent, and that a policy board consisting of the current members of the PKI can vote on admission of new members and the appropriate policy mapping. This is the current plan for the U.S. Federal PKI; the plans for the Bridge CA Policy Board are well advanced. The downside of policy mapping as described here is that, in the end, most policies are mapped into a handful of policy groupings, and little if anything is gained compared with the more basic Canadian plan.

Another eventuality is the proliferation of expectable policy OID lists that administrators will have to configure in their users' systems. This is similar to cross-certification policy mapping, but it is locally controlled and works without cross-certification (as in the current Browser certificate model, frequently called Trusted CA Lists). This approach moves the liability away from the certificate issuer to the local administrator. It also puts the local administrator on call to enable any new business by updating the excepted list. All three of these alternatives are unattractive. And yet, the Canadian approach is too simplistic for many communities. A middle ground is needed.

Smart Tags An X.509 object that functions as a permissible usage tag is just a number. Of course, there is a document somewhere that defines the business meaning of this number. But in the age of the computer, this is short-sighted. As much as possible, we need to define our business constraints in machine-processable form. Much of the content of CPs consists of operational requirements, such as CRL update timings or audit-trail retention periods. Such requirements could be stated in XML, and even some of the "soft" requirements such as key generation environment (user system, tempest system and so on) could have XML values assigned. With this capability, an administrator could define the rules for an application in XML and let the application evaluate the other party's policy to see if it is acceptable.

Take the case in which two companies have very similar CPs but one has a revocation cycle of four hours and the other 24 hours. The company with the 24-hour cycle could set its application policy to accept any certificate that has no more than a 24-hour cycle, thus it will "do business" with the company that has the four-hour policy. The company with the four-hour policy might accept signed e-mail if the CRL cycle is 24 hours but only encrypt transmitted e-mail if the CRLs are no older than four hours. Thus, local policy can match local business capability and business can still be managed.

XML in certificate policy is just an idea of a few people in the PKI development community, including Dr. Tim Moses of Entrust. Other technologies have been proposed as well. Dr. Matt Blaze of AT&T Research (www.research.att.com/~mab) has defined two policy languages, Policymaker and Keynote, for this purpose. This is shaping up to be the year of the PKI pilots. There are actually too many vendors in the PKI field now for large-scale strategies to play out. But as you begin to get a feel for local usage of digital certificates, remember that their global usage is the natural course of business. Somehow you will have to manage this larger problem. Spend the time now to evaluate the various leading-edge plans and add your voice to the debate. The PKI community needs more corporate involvement. Only a few industries, most notably financial services and banking, have been shaping the course of PKI-enabled applications. You can only reap what you sow.

Robert Moskowitz is a senior technical director of ICSA Inc. Send your comments on this column to him at rgm@htt-consult.com.