Are you certifiable?
Digital certificates are all the rage with the press and associated vendors. But where does the rubber meet the road? An interview with GTE CyberTrust Solutions's Joe Vignaly brings us up to speed
Digital certificates hold a lot of promise. They are standards-based, supported by many products and vendors, and could allow almost invisible strong authentication and non-repudiation. But how close is the promise to the reality? This month's column features an illuminating Q&A session with one of the major digital certificate vendors.
Also this month: plenty of bugs, an embarrassing online failure, and a pointer to certification information for firewalls. (1,600 words)
Pete's Wicked World: What is the state of the use of digital certificates for online commerce. Are they in active, widespread use or is that still the future?
Joe Vignaly: There are some companies using certificates in a "production" environment that are used primarily for intranets. However, most companies are evaluating digital certificates in application-specific pilots such as home banking, role-based access control, and secure messaging.
PWW: Can you give us some examples?
JV: Here are a few.
PWW: What are the benefits of using digital certificates?
JV: Digital certificates provide, with SSL-enabled browsers, the ability to conduct secure transactions with authenticated parties (i.e., you know who you are communicating with), and non-repudiation by those parties (i.e., neither party can deny that a transaction occurred).
PWW: What are the drawbacks of their use?
JV: Currently digital certificates reside in your browser on your hard drive. Which means that they are computer specific and are not portable. The limited portability will be resolved as the use of smart card-enabled hardware becomes more widespread.
PWW: What about interoperability? Can a user receive a "generic" certificate from, say, VeriSign, and use it when contacting a site that issues or uses CyberTrust certificates?
JV: Technically yes. Practically not yet. Simply put, the "acceptor" of the certificates must decide that the issuing policies of CyberTrust and VeriSign, or any other CA [certificate authority] or reseller, meet the criteria that the "acceptor" demands. The "acceptor" would just have to designate that in addition to recognizing the CyberTrust Root as valid. It must also recognize VeriSign, or any other root, as valid. Presently, businesses want to limit access and use their own root keys to issue private certificates (like CyberTrust Customer Branded Service). If public certificate use starts, then the need for interoperability will increase.
PWW: If a company wants to use digital certificates for online commerce, should they use their own CA or should they outsource that to a company such as GTE or VeriSign?
JV: Each company has to make that decision independently based on the business criteria that they determine appropriate at that time. They also need to be able to seamlessly change their choice of an internal CA or outsourcing the CA as time evolves. Companies should look for flexibility from their CA provider and not be limited to what that CA vendor happens to offer.
PWW: Are there any criteria that you can list that should be used to decide between internal and external?
JV: Some of the criteria are: numbers of certificates, existing level of IT administration, knowledge of physical/electronic security practices, ability to establish and staff a secure facility to meet business needs, investment criteria and cash flow requirements, availability of service (can business tolerate service outages, or must it be operational at all times?), and so on.
PWW: What does a customer need to do to be part of a financial exchange involving digital certificate authentication? Can you walk us through a customer wanting to perform online banking with a site that's a CyberTrust CA and using the certificates for authentication and non-repudiation?
JV: Customers would go to the bank Web page and click to the home banking application area. As part of the home banking application process customers would submit their certificate request which contains information that is placed in the certificate by the CA and other identity information used for verification. The request is verified and, if approved, the CA issues the certificate. Once the certificate is issued, the CA is not involved in the transaction.
In the transaction of the customer accessing the bank's home banking site, the Web server would do an initial authentication of the browser to ensure that it had a certificate issued by that bank or authorized CA. Depending on the criteria required, the back-end database would scan the certificate for the appropriate field (i.e. name, account number, etc.) and allow access to the account.
PWW: How complicated or expensive is it for a company to have its customers use digital certificates for authenticating online commerce to its Web facilities?
JV: The cost for a company to implement digital certificates for its customers depends on many factors including choice of insource or outsource, size of customer base, application types, and level of existing Internet infrastructure, if any. Like most new technologies, implementing digital certificates is not complicated after it's been done previously, which is a service that some CAs provide. Because the market is still evolving, the complete end-to-end solutions have not been fully developed, so there is some integration effort required by the company, outsourced CA, or system integrator. From the customer's perspective, the certificate is issued once and renewed periodically -- typically annually. The issuance process can be embedded with that company's online service application, so that receipt of a certificate is almost transparent.
Based on this exchange, it is clear that digital certificates are still in the early adoption stage. They do hold a lot of promise in terms of convenience and universal acceptance. Unfortunately, it may take quite a while before they are ubiquitous.
Before your company or customers run out and put all their valuable information on the Internet, they'd be wise to consider the recent credit bureau faux pas.
As reported by the Washington Post on August 17th, it seems that Experian Inc. (previously named TRW) created a service to allow people to view their credit reports online. Within 48 hours, the service was shut down because it gave users other people's credit reports. At the time of the shutdown, it was unknown how many of the 200 customers received the incorrect credit report.
It has been over a month since the incident, and as of this writing the service is still unavailable. I wonder if the designers and testers of this facility and those of the titanic are related?
Bug of the Month Club
If it were possible to have a sale on security bugs, this would be the month. A frightening number of bugs against Solaris keep turning up. Maybe it's time to start a bargain bin to unload some of them?
The NCSA has put together a formal certification program for firewall products. The certified products have passed a set of tests designed to determine their effectiveness. The certification list currently has 25 entries. An added bonus is that detailed information about the firewall, its features, and architecture is included in the certification write-up.
About the author
Peter Galvin is chief technologist for Corporate Technologies, Inc., a systems integrator and VAR. He is also adjunct system planner for the Computer Science Department at Brown University, a member of the board of directors of the Sun User Group, and has been program chair for the past four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Cameron at firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com