
Trusting the Access Control Universal Machinery has maintained a long working relationship with Acme Sprockets. Acme runs a high-trust-model CA (certificate authority) and has cross-certified it with Universal Machinery. Universal Machinery can delegate the appropriate enterprise OIDs to Acme via the delegation certificate: It creates a delegation certificate in its CA that states that Acme has rights to create attribute certificates in its own CA. Now, Jake no longer has to deal with phone calls; Acme's security officer can create the attribute certificate for June and revoke the one for Jan. Universal Machinery's expediting application would find this new attribute certificate, and June would be in the system.
In another case, Fred's Tool and Die doesn't want to run its own CA and buys all of its certificates from BIG ISP. Universal Machinery trusts BIG ISP to properly identify people at companies, but does not trust it tocreate attribute certificates for only those people at companies specified by Universal Machinery. In this example, Universal Machinery does no delegation, but creates the attribute certificates for the expediter at Fred's Tool and Die in Universal Machinery's CA. Again, the expediting application will find the attribute certificates and only permit access to the proper people at Fred's.
This approach provides the ability to move access-control maintenance as close to the responsible source as there is trust. Further, it eliminates the need to create an access-list maintenance mechanism in every application. This is a function of the PKI. Clients need not be changed to support attribute certificates as long as they supply servers with user certificates. Only servers need this functionality.
No Bed of Roses This theory is sound, and a handful of pilots have shown that it can work. But there are some thorny issues that need resolution, and much of this depends on users. PKI has always been a chicken-and-egg situation. No one wanted to build anything relying on digital certificates until a PKI existed, but no one wanted to build a PKI until applications demanded it. We need to get over this and start our part of the PKI. No matter what your initial justification is--e-mail, TLS (Transport Layer Security) or IPSec (IP Security)--get your share done.
The next phase is to choose a high-maintenance, less-critical application and make it use attribute certificates. One success will lead to more effort. At first, you may not be able to delegate to a cross-certified CA, but try for at least one and document the change it produces. Initially, you will be restricted by your choice of CA and server software; not many support attribute certificates. Very few vendors feel there is a market for them. Also, attribute certificates are an open standard that might be considered difficult to implement in some vendors' minds, so they instead create proprietary solutions that do not significantly reduce administration workload.
Attribute certificates may well be the killer application for your contribution to the industrywide PKI. They offer the potential to move the administration workload closer to the user, without creating an excessive workload burden at that end.
Robert Moskowitz is a senior technical director at the International Computer Security Association and a member of the Internet Architecture Board. He can be reached at rgm@htt-consult.com.
|