What Should VeriSign Do

 
 
By Larry Seltzer  |  Posted 2005-03-03 Print this article Print
 
 
 
 
 
 
 


?"> As with many loud arguments, Edelman, VeriSign and I agree on a lot. Its drowned out by the noise of the disagreements. We all agree that the whole point of the system is trust. We all agree that abusive certificates should be revoked. Edelman argues that VeriSign needs to do more to end abuse of its certificates. Given its overwhelming market power, Edelman feels that VeriSign should be out there looking for the abusive examples that he finds on his own. VeriSign says that right now it gets tips for such problems from other aspects of its business, such as its payment processing and e-mail security businesses.

I think VeriSign would do well to enter into a relationship with an anti-virus/anti-spyware company and have them report signature information on malware they find. Such companies are already in the business of collecting the sort of disgusting stuff Edelman writes about, and they compete to do it as quickly as possible.
How hard could it be for them to scan for signature information and report it to VeriSign along with criteria specified by VeriSign for potential violations of policy?

Edelmans right about another thing, and VeriSign tells me it agrees and is following up on it: Users need to have an easy option to report abuse. VeriSign says it will listen to complaints sent to support@verisign.com, but its hard to feel good about big catch-all addresses like that. Instead, there should be a big fat, red link on the home page.

But I have to sympathize with VeriSign more than Edelman about some of the tough cases he cites. Maybe "Virus Free" is a misleading name for a dialer program, but if the program discloses everything it does and gets assent from the user, then Im not sure its right for VeriSign to revoke the certificate. If I put out a new Debian-based Linux distribution and call it "Easy Linux," that might be misleading, but is VeriSign really the authority to call me on it?

Edelman also points out that VeriSigns policy for revoking certificates for, as it terms it, security purposes, is nowhere to be found on its site. Ive asked VeriSign for the written policy and have not heard back yet, but they told me verbally that they absolutely would revoke a certificate used to sign, for example, a virus. Of course, its the ambiguous cases that are really at issue. Its also possible that the certificates in all of Edelmans examples have been revoked. This is difficult to confirm.

Since its important for code signing to become more pervasive, its as important for the price of them to go down. Demanding that VeriSign assume new policing functions is likely to increase prices by increasing VeriSigns costs, so I can understand the companys hesitation. And they are adamant that they already spend a lot of time and money verifying applicants and assert that they block many attempts at abuse at the application stage. Its not clear what level of success to expect from them, but expecting perfection is unreasonable. At several hundred dollars a pop, a code-signing certificate is not something to blow casually. Its possible that if VeriSign were more aggressive about pursuing dishonest customers, it would not see benefit in signing its programs with VeriSign certificates. This is all obviously in VeriSigns best interest, so maybe the company will see it this way and save Ben Edelman the trouble from now on.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog. More from Larry Seltzer


 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel