Interview with Jon Callas, CTO of PGP Corporation
Jon Callas is an innovator and an acknowledged expert in all major aspects of contemporary business security, including cryptography, operating system security, public key infrastructure, and intellectual property rights.
For how long have you been involved in the development of PGP?
I joined PGP, Inc. in January 1997. I was Chief Scientist there. When NAI bought PGP in December 1997, I became CTO at NAI, and stayed there until April 1999. I am one of the co-founders of the new PGP Corporation.
I am the principal author of The IETF OpenPGP standard, which is presently RFC2440, and have been doing that since mid ’97.
What were your thoughts after Network Associates stopped selling PGP products this March?
Oh, I was incredulous! I’m a Mac OS X user and had been on the beta list for it in October. I kept waiting for them to find someone for it, myself.
When and with what plans was PGP Corporation started?
Phil Dunkelberger and I ran into each other at last year’s RSA conference, and started talking about a new security startup. We came up with some ideas on how to make message security much simpler to use. We then started working with Will Price, who had then recently left Network Associates after the PGP cancellation. He had his own ideas that meshed in with our ideas, and that led to us deciding that PGP would fit in well with our combined plans.
What products were bought from Network Associates?
We bought all products from Network Associates, including ones that are in progress except for the Windows VPN and firewall, and the command line versions. Network Associates still sells the command line PGP under the name McAfee eBusiness Server. We are under an eighteen-month non-compete for the command line PGP, so it is theirs for that time.
Our products include the traditional PGP for Windows and Macintosh, the Palm and WinCE products, the PGP key server, and so on.
What’s your opinion on open source?
I think if you buy a software product, especially one that is a security-related product, you should be able to know how it works. You should be able to see that it doesn’t have horrid flaws in it, by accident or design.
We haven’t quite worked out the details of PGP’s open source license, but here are the goals I have, pending language:
If you have a legally obtained copy of PGP, then you read, compile, modify, hack, etc. the source for that type of PGP you have, for your own purposes and not for redistribution. What I mean by this is that if you have PGP freeware (which you are using for non-commercial use), then you may do all those things with PGP freeware. If you bought a copy of the retail product, then you may do those things with the retail product or the freeware product.
This isn’t quite the same as what some other open source people believe constitutes “open source,” but our philosophy on source is completely in line with the principles that the FSF and LPF were founded to defend — the right to look under the hood.
Part of the reasons we’re of this mind is that as makers of a security system, there are safety and reliability issues that we have to deal with. We have a responsibility to combat the appearance of PGP clones that are of lower security. Worse, what constitutes “lower security” is something about which gentlepersons can disagree. I know some people with extreme opinions about all sorts of security issues (including us). I, personally, as the OpenPGP author try to be moderate. There are things allowed in the standard that personally I disagree with. We solve that by saying that in our implementation of the standard, we’re not going to do those things. You can think this as being the software equivalent of having an editorial voice. I’ll defend your right to use feature X, but it isn’t going in my product. But I digress.
I support your right to look at my software. I think it’s fine if you modify it for your own use. If you quietly give it to your friends, I’m not going to complain — provided they’re using freeware features or paid for it.
We provide reseller agreements and we license our toolkit, the PGPsdk — quite liberally, I might add. If you want to do resell or make a product
based on our source code, we can work something out. You just need to talk to us first.
After stopping the PGP product line, Network Associates spokeswoman Jennifer Keavney said: “The reality is it didn’t become a large enterprise sell, and it maintained its perception as a freeware product. People around the world are still using it for free”. Won’t PGP Corporation have the same problem?
We believe we can be successful. Our funders, who include Venrock, the venture arm of the Rockefeller family, believe we can be successful.
Will your company stop offering PGP source code in the future?
No. Source code is vital. We believe in it. Our funders believe in it.
Will PGP Corporation produce Linux versions of PGP products?
We are considering it. We can produce a GUI version of PGP similar to the ones we do for Mac OSX and Windows. The biggest question for us is whether or not Linux people would find such a thing valuable enough to want to buy. There are a number of freeware systems available now — should we bother making something we charge for, or should we just interoperate with what’s out there?
Are there plans for the development of new products in the PGP line in the near future?
Oh, yes. We weren’t funded just to pick up the PGP business. We were funded for our new product plans. Without giving it away, our aim is to make products that are extremely easy to use. Think of it as PGP for people whose VCRs flash 12:00.
Is there a possibility for you to discontinue any of the PGP products?
I can’t think of one.
What do you think about the whole segment of handheld computers security? Where does PGP Corporation stands at this topic?
We already have versions of PGP for Palm OS and WinCE. We have Symbian’s OS. We believe this is a huge opportunity for us.
What is your perspective on full disclosure of vulnerabilities?
I am a proponent of full openness. I’m a proponent of published source code, so by necessity vulnerabilities will be disclosed — just look at the differences in the source.