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?"

Comments

Zimmerman has it right .

[Ckwop]

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:

1. Nobody actually reads the certificates.
2. Even if they did, they don't really mean anything anyway. How difficult is it to get a real certificate with fake credentials?
3. Moreover, if the URL is similar enough to the target of your phish then your SSL certifcate may well be legitmate in every sense of the word but you trick people because the URL is close enough to a big brand's main domain.

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

Re:Zimmerman has it right .

[Anonymous Coward]

That is incidentially how SSH authentication works. The host key is cached along with the host name, so if it is different the next time you connect, you'll get a big warning.

Re:Zimmerman has it right .

[Workaphobia]

Credit cards simply should not work based on knowledge of a stupid number. Change the system so that every transaction is authorized through a direct communication between the cardholder and credit card company, and you've eliminated the danger of not knowing which merchants to trust with a common number.

Re:Zimmerman has it right .

[billcopc]

While that concept works great in other realms, the truth is Visa has no interest in reducing fraud. They profit from fraudulent transactions, and so do their customers. The ones who are hit hardest are the sellers, as not only do they have to pay ridiculous chargeback fees, they often lose the item they were selling.

Let's say you buy something off the net, then call a month later and declare the transaction as fraudulent.... IMMEDIATELY they yank the cash out of the merchant's account, send you a cute little form you have to sign and fax back, and a week later they refund your money. You get to keep the item because you have the benefit of the doubt, or to be more precise: Visa and MC treat all merchants as guilty by default.

One time I had a customer buy an item, a hard drive for example. Then once the card went through, he decided he wanted another one (twit). So I cut him a second invoice and charge the card again for the same amount. A month later I get a letter regarding the 2nd transaction being a "duplicate", that it had already been reversed and a hit filed on my record. It took another couple of weeks of me faxing serial numbers, signatures and ultimately sending video proof from my security cameras (with sound). I was just about ready to go reclaim the hard drive in person and rip the guy's head off. A month later a supposed review committee decided in my favor "in light of evidence provided".

Now I was providing physical products with a clear evidence of the transaction. I can only imagine how horrible the problem is for mail-order and online transactions. How can a merchant prove they sold something if they've never met the customer ?

In reality...

[tomstdenis]

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

What is the question?

[smallpaul]

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.

Root certificate inclusion is expensive

[wizman]

Having an open source CA is one thing. Having the root certificate included in major browsers is an expensive endeavor. The www.cacert.org site has an FAQ entry about this:

http://wiki.cacert.org/wiki/InclusionStatus

Summary: Lots of open source browsers already have the cert; Mozilla/Firefox will have it soon. Internet Explorer (and apparently Apple's Safari) won't have it unless they come up with a way to pay for the $75,000+ plus $10,000 a year for a AICPA WebTrust audit.

Certificates are a scam

[Anonymous Coward]

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.

We already have

[Watson Ladd]

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.

Main use would be code-signing

[badzilla]

It's already possible to get SSL server certificates for a few dollars; these "work" in the sense of not triggering scary browser messages but are essentially worthless in the sense that they do not provide any further positive identification of site ownership. Unfortunately it's hard to see how anything "open source" could improve on this, unless the open source CA were willing to provide background-checking services for free.

It's also already possible to get high quality free/beer personal identification certificates for example the Thawte Web Of Trust who issue personal certs based on real-world check of national ID such as passport.

What we really need from an open CA is something you cannot to my knowledge get elsewhere which is reliable code-signing certificates without spending hundreds of dollars.

Awesome!

[222]

Sounds great, maybe one of the Ubuntu guys can help? How about that one guy?

Re:Advertise it for other than e-commerce.

[TheRaven64]

I use a CACert certificate on a couple of mail servers, for outbound SMTP and inbound POP/IMAP. If I need to re-create the certificate, none of the users has to know anything about it, as long as they added the CACert root to their client; the old and new ones are both signed by the same root, and so it just works.

I don't really understand what the original poster meant by saying CACert is not open source. Open source doesn't really apply to something like a certificate authority, because they are not providing software. Anyone can get a CACert certificate at no cost. All you have to do is show two forms of government-issued ID (one with a photo) to an existing member. The more people who assure you in this way, the better the certificate you can get, and eventually you are allowed to start assuring people yourself. The problems I see with CACert are:

1. There is not yet a good infrastructure for assuring organisations. Non-profits would benefit a lot from this kind of thing.
2. There is no good revocation mechanism, nor a good verification mechanism. The points A gets from being assured by B and C are the same, even if C was assured by B. It would be better if you had to be assured by people from divergent branches of the tree.
3. Due to the way IE handles root CAs (i.e. pay lots of money), it is not likely to get in there for a very long time.

Encryption and authentication are conflated

[Alain Williams]

It is useful to have the communication between the server and web browser encrypted, this is what https (port 443) is all about. It would be useful to be able to ensure that you are surfing the web site that you think you are ... https purports to do this, but does not do it well - as others have said.

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.

Re:am I missing something here?

[Solra Bizna]

You're welcome to teach my grandmother how to personally audit every line of source code for every program she ever installs.

Certificates have other uses than blob signing. If nothing else, the current infrastructure of "web" certificates would allow you to verify that the mozilla.org you're about to download and run executable code from is mozilla.org and not some leet h4xxor who owned your ISP's DNS server. They're also supposed to be able to verify that it's Amazon.com Inc. you're about to give your credit card number to and you're not really at a carefully cloaked amazonn.com but in practice that kind of protection isn't dependable.

I wish the Mozilla foundation would get a cert; AFAICT they don't have one and it freaks me out whenever I download an extension....

-:sigma.SB (the paranoid)

Thwaite, eh?

[zCyl]

I trust Thwaite a whole lot more than I trust an Anonymous Coward on Slashdot.

Thanks for proving a key point:

Thwaite

Thawte

Re:Great idea

[fyngyrz]

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