eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The first thing I need to do here is to correct some misstatements from a recent column titled, Should VeriSign Be the Name Police? For that piece, I spoke with VeriSign about a column by Spyware researcher Ben Edelman that enumerates examples of VeriSign certificate abuse.
I was told by VeriSign that they had contacted Edelman about the specific examples and that the certificates had been revoked before his piece had even gone up. Edelman quickly disagreed with this account, and I checked back with Chad Kinzelberg, vice president at VeriSign, who now confirms that he was mistaken in saying this, and he apologized.
I should apologize, too, for not checking back with Edelman first, but Ill set the record straight here.
In follow-up discussions with both Edelman and VeriSign, we got to the heart of the matter, which is the basic utility of code signing. To recount, VeriSign sells digital certificates for a variety of purposes, and in fact dominates this market.
The vast majority of this market involves certificates sold for secure Web sites, which are unrelated to the issues Edelman brought up. But certificates are also sold to sign executable programs.
The point of signing programs is that a user can check the signature on the file, confirm that it was signed by the entity they expected as the source of the program, and also confirm the validity of the signature itself by seeing the CA (certificate authority) that issued the signature.
Certificates cost several hundred dollars typically, and part of what you get for that money is that the CA scrutinizes the name used by the applicant to ensure that it is theirs to use and doesnt otherwise violate policies. Click here to see VeriSigns policies for such certificates.
I think that in the world of the Internet, such a trust system is essential, but in fact its still in its infancy.
With rare exceptions, the only time users check a code signature is when Windows XP SP2 (Service Pack 2) forces them to. Microsoft has been a driving force in the industry for code signatures, but they drive like my grandmother.
After hearing about signatures for about eight years now, its only with Windows XP SP2 that they really force the user to deal with them in most important circumstances, such as when you download and run an executable from the Internet.
Microsoft shows the certificate information, but not the CA information. Of course, the company has supported code signing of ActiveX controls since their inception. Edelman cites several examples of ActiveX controls that exhibit the problems about which he writes.
Next page: What should VeriSign do?
What Should VeriSign Do
?”> 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