Is It Time For an Open Source Certificate Authority?
cagnol writes "So far there are three free ways to get a free certificate to sign your email and receive encrypted communications: Thawte, Comodo and CAcert.
Thawte's root certificate is in mainstream browsers. Thawte's interface is good and the web of trust allows for increased security by verifying people's identity. However Thawte is not open-source; worse: it is owned by VeriSign. Comodo's root certificate is in mainstream browsers too but there is no web of trust and their forms are not always working.
CAcert is the closest to an open-source certificate authority but is not open-source and it seems that parts of the system are shaky. CAcert provides a web of trust. Unfortunately, CAcert's root certificate is not in mainstream browsers.
Don't you think it is time for a true open-source certificate authority? Should this community be related to the Mozilla Foundation and comply, since day one, with the requirements to get a root certificate in Firefox?"
I've fell out of love with public-key signature schemes as a means of proving authenticity. There are a few problems with the idea in general:
I think Zimmerman, with his ZPhone program, has got it right. Really, all you're interested in for E-mail or VoIP is not whether the person really is Simon Johnson, of Widnes, based in the United Kingdom who is 23 years old with a pet dog called Thornton. You're actually interested in whether this Ckwop guy I'm speaking to now is the same guy as I spoke to last-time.
When you weaken your security requirement to this position, you can remove a staggering amount of complexity. You can cut out all the CAs, all the X.509 certificates and ASN.1 implementations etc. What you're left with is Diffie-Helman and AES in CCM mode. You can implement this in a couple of thousand lines of provably correct code and your done.
The real way to solve the "identification problem" with web-sites is to change the way credit-cards work. You have a secure token that outputs a different string every thirty seconds. RSA have made these but they're very expensive for no explicable reason, the banks would develop an open-standard in my model to drive down prices. When you pay for something, you submit your credit-card along with the token's value. The transaction will only be authorised if the token's value matches what the bank thinks that value should be.
That way, phishers only have one shot to take your money. Sure, they could make a mock payment page but the auth-code is only going to work once. I think this would destroy the cost effectiveness of phishing for credit-card numbers. That said, identity theft would still be an issue.
Simon
They shouldn't be issued by private corporations but instead by the man who issues the business licenses. Otherwise, it's meaningless. So I setup p4ypal.com, buy a cert and trick people to go there. Whoopy.
What do certs really mean anyways? Just because company.com has a legit cert from verisign doesn't mean they're a good company. It means that I'm talking with company.com. Big deal.
Tom
Someday, I'll have a real sig.
The question posed is "Is it Time for an Open Source Certificate Authority?" But the description does not address the question. Rather it addresses the question of whether there is an open source certificate authority. First: someone needs to define what it means for a service to be "open source". Second, they need to describe why anyone should care whether a service is open source. That would be a better start to the dicussion than a laundry list of certificate providers.
I've been saying for years that security certificates are a scam. Everybody knows it's a meaningless number. You can write your own security certificates. With the choice between paying $100s to some shady "security company" or generating your own for free what would you choose? Face it, certificates are another barrier to trade and security compaies are greedy mafia and nothing more. How can Thwarte or Verisign or whatever be at the root of a "web of trust"? Trust from whom. Not from me. And if I'm writing the system who gets to say what is and isn't trust? From the uend users perspective, the only person that matters, they never heard of Twarte or Verisign. How would they know a certificate from those companies from another you made up with an impressive sounding company name like UltraSecure or SafeClick? It's a meaningless game. And it's not like this "trust" gives any party some legal recourse or adds accountability to the operator. Yep, Open source certificates all the way. Anyone can set up a verification system selling zero cost numbers to strangers if they sign a form or show their driving licence or something, but it wont make anybody or anything more secure.
It's called GPG. It can be used with TLS as GNU TLS demonstrates. The one issue is making sure that GPG/TLS is implemented more widely.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
"So far there are three free ways to get a free certificate to sign your e-mail and receive encrypted communications: Thawte, Comodo and CAcert."
I must be missing something, because the first thing I thought of was PGP that we've had for 16 years.
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
The problem is that if you want encryption, you either buy a certificate or you have the user presented with a misleading dialogue box that suggests that you are not trustworthy ... or rather the reverse is not true: just because you have a certificate does not mean that you are trustworthy.
Joe Sixpack does not understand the difference - which is only good for the profits of Versign and friends.
It would be nice if the two could be somehow unlinked.
The idea is sound enough, it just doesn't go far enough.
Certificates and the technology surrounding them provides two things, one of them useful, one of them harmful. The useful thing is encryption. This means that as your data goes from point A to point B, it is very, very difficult to make any sense of. This is useful because often, as in the case of when we share our credit card data with some other entity, that is as far as we meant to share it and the encryption erases one of the situations where it is highly vulnerable to interception by others. We definitely want encryption.
The harmful thing is the illusion of "identity." This is 100% harmful, and on several fronts. First, the idea that you "know" who, or where, you are "locking certificates" with is illusory. No mechanism within the process positively or reliably identifies where, or which, computer you are connecting with, only that the certificate at hand has, at some point in the last year or more, been issued by a "certificate authority" that was convinced to some degree that at the time the certificate was issued there was somebody at a phone number and an address, possibly with a business, possibly not. They could have moved 20 minutes after the certificate was issued, and they'd have [certificate expiration time] to fraud up a storm if they so chose. In no way does the actions of the certificate "authority" serve to determine if that entity had nefarious intentions, or if the transaction you are entering into at any one time is legitimate. So you don't know who, or where, you are "locking certificates" with, and nothing the "certificate authority" does even begins to help you out in this manner. Despite very expensive marketing campaigns claiming precisely the opposite, gaining the consumer's trust with glossy, high end advertising.
But things are even worse, because with that illusion of "trust", the impression that the consumer no longer has any reason to check out the business is quite strong; this is partially a consequence of the method, but it is also a marketing lie told to consumers, and there the responsibility rests upon the promulgators of the scam, the "certificate authorities" themselves.
The fact is, as a consumer, you have to determine the legitimacy of the business yourself, and if you don't do that, there isn't a single thing that the "certificate authorities" have done, or can do, that will reduce your risks.
Now we come to the idea that to be useful, certificates have to be issued by a certificate authority. This is entirely false in terms of service, but entirely true because there is a huge scam going on.
Service-wise, a vendor can produce their own certificate, 100% as effective at encryption as anything they can get from the "certificate authorities." That certificate is 100% capable of working with any browser and protecting data during transfer to the connected party as well as anything they might get from a "certificate authority." So effective encryption 100% identical to what everyone uses now doesn't require a "certificate authority." Period.
Scam-wise, not the certificate authorities, but the browser vendors (though certainly encouraged by the "certificate authorities"), have created a situation where if the certificate you have cannot be traced in origin to one of the "certificate authorities", then the browser will pop up a warning and scare the dickens out of the consumer, thereby eroding your ability to do business. Consumers don't understand what is going on, all they know is they got a WARNING OMG WTF.
Therefore, to do e-commerce, a vendor must use a certificate from a "certificate authority" or they will have shot themselves in the foot. It would be the work of only a few moments for each of the browsers to remove these untrue, scam warnings; at that point, any properly generated certificate would work to provide encryption, consumers would stop getting these baseless warnings about "identity" t
I've fallen off your lawn, and I can't get up.
Exactly, and if you want to be a CA you should be looking at very high security hardware such as the Chysalis or n-Cipher products which are FIPS 140-4 certified.
I think that the premise of this whole article is wrong. What people need is an open source mechanism for communicating securely. The most practical model is almost certainly not going to be a CA. Unless you are going to be serious about the authentication criteria you might as well use self signed certs.
The whole point of the CA model is to concentrate trust in one link of the chain and to lock it down with really tight security. Thats not the sort of project that fits the open source model well. Anyone want to try open source heart surgey? How about open source tax accounting?
People might have fun setting up a CA but running one is about as interesting as watching paint dry. Particularly if nobody is going to be paying you to do it.
If you want to go this route get rid of the CA entirely, just make sure that you also get rid of any security indicators that might give the user a misleading indication of the level of security being achieved.
And don't just fixate on Phil Zimmermann, look at the ideas of people who made the web of trust model work, like Brian LaMachia. Look at ideas like SDSI/SPKI that Rivest and Lampson worked on. Take a look at XKMS and DNSSEC.
Above all start by deciding the use cases you are going to be serving. If you want to support online commerce the level of trust you have to achieve is going to be very high. if on the other hand you want to allow people to read their email or post to their blog over SSL encryption the barrier is much lower.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
As I said, it is up to us to take responsibility for what we are doing. Who typed the address in wrong? And since the answer is the user - us - then whose fault would that be? Not the legitimate businesses, and not even the CAs; No, it is the ours. And my precise point is that we should be careful with what we do, the certs don't help in any way to ensure we are where we meant to be. For that, we need our eyes, our memories, and our wits.
It isn't limited by it, it never existed in the first place. Customers - IOW your average netizen today - look for the lock indicating encryption is on. If they look for that. There never was any value here, it is entirely illusory, the product of a very powerful marketing campaign. It's a scam, one that will only evaporate if the browser manufacturers wake up and realize they are the fools in this chain of fraud - they get no income, they screw the vendors, and they enable the scammers - the "certificate authorities" - to rake in huge amounts of money for no service, unless you call deceiving Internet e-commerce customers a "service."
Again, no. Reputable people will be right where they said they would be. Which doesn't help, because you're not looking for them. Scammers will not. You can send the process server to the address on the certificate, but they won't be there. Cert authorities only check (if they do check at all) that you are where you say you are when they issue the certificate. The same day you get it, it can be installed on your laptop, and the very next day you can be taking orders a thousand miles from there. The cert authorities don't have any idea of your post-purchase whereabouts, nor does the address on the certificate help even a little bit.
That's my precise point. They don't do any such thing. They can't. Where the scammer was the day the cert was issued is in no way tied to where they are when you try to go after them.
I've fallen off your lawn, and I can't get up.