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 .

[Workaphobia]

I don't think I understand how your statements follow from mine. How is authorization going to require infinite employees answering requests in finite time? Why are employees even involved?

Re:Zimmerman has it right .

[kestasjk]

Nobody actually reads the certificates.

Nobody has to if you trust the certificate authority. What use is reading it anyway, if it hasn't been signed by a CA/friend and can be tampered with?

Even if they did, they don't really mean anything anyway. How difficult is it to get a real certificate with fake credentials?

If a CA is worth its salt, nigh on impossible; that's what you pay those ridiculous prices for (at least, that's where the money should go). This is the main problem with an open CA; there are presumably fewer security checks that the person requesting the certificate is who he says he is.

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.

That's a phishing problem, not a crypto problem.

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.

This is exactly what happens when you cache a certificate which hasn't been signed. If you go to, say, https://hackinthebox.org/ you will get a certificate warning because it hasn't been signed. You don't know if anyone has replaced the certificate along the way, but once you have cached the certificate you can be sure that you are securely communicating with whoever sent you the first certificate. Using a certificate authority means that you can also be confident that the person who sent the first certificate are who they say they are.
So whatever the ZPhone is, it sounds like plain old certificate-less public key encryption.

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.

Ensuring secure code doesn't bother me, I'm much more interested in having secure protocols. There's no point of having "provable code" if all the protocols are vulnerable to man-in-the-middle attacks (the attack which certificate authorities are designed to prevent).

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.

Credit cards? 30 seconds windows during which my money is accessible? We already have things that are better than this.

As regards the Certificate Authority issue here is the rundown as I see it:

• The current way things are: CAs are very expensive, which means sites often don't use any encryption at all.
• Having an open certificate authority: Who pays for properly checking that a person is who they say they are?
• A key signing network: This is the idealistic approach, done at the moment in GPG keyservers; Everyone signs their friends' keys, who sign their friends' keys, and a web of trust is built up. It takes effort though, and there are still trust issues.
• A government CA: The government assigns public/private keys to individuals and bus

Re:Zimmerman has it right .

[bcrowell]

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.
A couple more reasons why a free certification authority is not as useful or feasible as one might think:

1. The traditional service is useless unless someone is going to check on the real-world credentials of the person applying for a certificate. That means there have to be office workers sitting around in cubicles processing paperwork: please fax us a copy of a recent utility bill, blah blah blah. Does that sound like fun, or does it sound like work? Does it sound like something that Mr. J. Bearded Hacker feels like doing all day as his contribution to the free information movement? Sure, theoretically you can have a web of trust based on key signing parties, etc., but in reality that's never taken off to the point where it was a useful option for most businesses.
2. I think a lot of people who complain about the expense of certificates are individuals who would like to set up their own apache server and take credit card transactions via https. The fact that they're worried about this particular expense tells you that they're probably hobbyists who aren't serious about running a business full time. Well, I've had some experience with taking credit card transactions for a hobby business, and I can tell you that you just don't want to do it. Setting up a merchant account is a lot of hassle. Dealing with transactions is a lot of hassle. You're actually setting up a business relationship with three or four different companies that are involved in the process, and when there's a problem, each one will blame all the others. You're dealing with customers who use stolen cards. You're telling the companies your banking info, and then as time goes on they start putting mysterious monthly charges on your account, which you have to fight them about. If you're making a living by running a restaurant, then by all means, you need to have a merchant account. If you're a hobbyist, you should find some other way to handle transactions.

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 ?

Re:Zimmerman has it right .

[iabervon]

Public-key crypto is still useful so that people can have a certificate that they keep really secure which signs certificates that they carry around and use. Furthermore, it's useful for cases where you want to know what somebody else thinks: this really is "that site that my friend recommended" or "a company known to the state of California". The problem isn't PKI, it's the notion that (1) signatures without assertions mean something, (2) "authenticated" without a user-meaningful identity means something, and (3) there are authorities who know globally useful information.

The way is should work is that the browser remembers certificates it's seen before, and allows the user to make statements about certificates which are then used to inform future interaction with the certificate. E.g., when I go to my bank's secure web site the first time, I get a little note that says "this site has a certificate that can be used to identify it in the future". If I click on the note, I get a window that lets me say, "Recognize this site as: My Bank". Then it asks me how I know. I compare the fingerprint on the screen with the fingerprint on my latest bank statement, and they match, so I check off "I verified the fingerprint" (the default was: "I don't really care if the wrong site is identified as 'My Bank'"). From then on, I expect to see a little bar in the browser when connected to my bank that says: "This site is recognized as 'My Bank'" with decorations to see that the recognition is good. If I didn't check off anything for how I knew, there would be a bunch of question mark decorations.

Other options would include: "I trust the chain: US Government recognizes Massachusetts Government as A State Government, and Massachusetts Government recognizes this site as A Massachusetts Bank." This would get the site a decoration with some little flags and some question marks, indicating that I'm at a verifiable business, but I could be at entirely the wrong legitimate Massachusetts bank site, because nothing in the chain of trust says it's actually my bank. (This is the chain that you'd usually use for e-commerce; you don't know anything about the site other than that it's a business that the FBI could find, but that's all you need to know to buy a lamp from it. But if you got here expecting it to be the place you got the matching table from, and your browser doesn't recognize it, you're probably at some other store.)

Re:Zimmerman has it right .

[vux984]

That's essentially what paypal invoices are if you've got your CC setup.

You make purchase.
Vendor sends you paypal invoice.
You pay paypal invoice.
Paypal charges your card.
Paypal transfers money to merchant
Merchant sends you product

Works like a charm.

Except I hate paypal.

Sure wish Visa/MC/Amex would just implement this directly:

You make purchase
Vendor sends you Visa "Net" Invoice
I log into Visa "Net" and authorize it.
Visa transfers money to mercant and charges may card.

Oh wait... they did. Its called "Verified by VISA".
The difference is that as part of the merchant checkout I'm actually directed to the Verified by Visa site to authorize the transcation directly with VISA, and then routed back to the vender site. Its all pretty slick.

The ONLY issue with the system is that its vulnerable to phishing etc. How do I really know I've really been directed the Verified by Visa site? The merchant directed me there, I didn't go there myself. But really what can be done to fix it?

If they disconnected the process so I had to manually log in to VISA and auth the transaction, it wouldn't really be any safer. Merchants are going to want to be helpful and they'll include a link to the Visa site, which might even take me directly to the transaction. But that link could be a phish site! Even if VISA banned the practice of merchant including links to VISA to force users to use their own bookmarks or whatever that would accomplish nothing:

Legit merchants would be frustrated as idiot customers wouldn't complete the transaction. Shopping carts would get stale. In cases of hot products like the Wii, what do they do while they wait for customers to finish authorizing. Hold it? Or Sell it? It could be days before the customer gets around to logging in.

(I mention Wii because I've tried to buy one 3 times online now, and twice they've sold it out from under me WHILE I'm going through the checkout. Worse, they check my cart for availability before going into the checkout [I know this because I've had it happen a couple times that I got the item into my cart, but then couldn't even get into checkout as it had sold out], and then at the final submit after entering CC info etc they've sold it right out of my cart.

I understand not holding the cart contents for 24 hours, but come on... 3 minutes from pressing checkout?! Sorry, Just venting... My last order finally got through checkout so hopefully I'll actually get one this time.)

Meanwhile Illegitmate vendors will ignore the ban on links, and provide them. Customers ignorant or uncareful enough to fall for a phish attack, will fall for this too.

I don't know what the solution is, beyond requiring the customer to be slightly paranoid, and constantly vigilant. (And that's somewhat unrealistic.)

One solution I do think would work is a dedicated hardware solution. Where the vender displays a transaction number on the screen. I insert my card into an 'interac debit machine like box' punch in the transaction number on the boxes keypad, and perhaps a password, and the box communicates directly with VISA, to authorize the transaction. I'd even pay a one-time $50-$100 bucks to buy such a box, which is *entirely* feasible as it wouldn't really be anymore complex than a cheap nat/router.

The BOX would interact with the visa web site (web service), it would check certificates (to avoid dns spoofing, phishing sites, etc), and wouldn't be nearly as easy to fool as a person. And as a dedicated box, using certs, public key encryption, SSL, and other appropriate technologies it would pretty much take a firmware hack to defeat it.

It could probably even be made to work via USB to an internet connected computer instead of requiring its own network connection, and still be secure. Even if a virus/trojan replaced the drivers, I doubt they could perform an effective man-in-the-middle attack; all they'd get to see is encrypted traffic and a destination. Splicing it, or redirecting it wouldn't accomplish anything. There's even no reason that the system couldn't be available for Linux, or even GPL/OSS, as it doesn't rely on TPM/DRM at the OS level.

Dammit. Now I want one. :)

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

Re:In reality...

[pjt33]

Why should certificates be tied to business licences? You don't have to be a business to want to use SSL with your website.

Advertise it for other than e-commerce.

[grahammm]

All of the current CAs seem to over emphasise the use of certificates for https servers and e-commerce. Their web sites mention this usage almost exclusively and if other uses of certificates are mentioned they are hidden away.

So if an open source CA is set up, it would be good for it to give more prominence to other uses of certificates, such as S/MIME, starttls for mail servers, for VPN authentication etc.

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.

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.

Re:What is the question?

[Proud like a god]

Story: Are there any free, reliable Certification Authorities?

New question: Is it possible for a Open Source CA system to exists, as this would help ensure these qualities?

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.

Re:Certificates are a scam

[tepples]

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? If you generate your own certificate, how do you 1. convince end users to install your certificate and 2. teach end users how to install your certificate?

Re:Certificates are a scam

[mollymoo]

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?

Everybody knows it's a meaningless number? Your grandma knows that, does she? Very few people know anything about certificates at all. All they know is that if they go to Amazon's secure pages, a little padlock appears and they've previously been told that this means it's secure. If they go to your site with your self-signed cert, it asks them whether they want to trust you. If this is for e-commerce, you've just lost most of your customers. Normal people trust their computer, they trust their web browser. If Microsoft or Mozilla say they trust Thwaite and Thwaite say they trust Amazon, the user trusts Amazon. If Microsoft or Mozilla don't trust you, the user is much less likely to trust you.

So, if you want anybody but the most technically knowledgeable to trust your certificate, you pay a couple of hundred bucks to the "shady" security company. I trust Thwaite a whole lot more than I trust an Anonymous Coward on Slashdot.

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.

Why OpenSource?

[cybrangl]

Right now there are plenty of free certificate authority programs out there. The only difference is that the authorities are not trusted by the browsers. If you could have every authority trusted, the certificates would mean even less than they do now. All we really need to do is take the methodology CAcert uses and add their authority to the browsers.

Awesome!

[222]

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

Re:CACert TTP program

[crush]

Here's a link to the paperwork, and here's some info about it

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.

How do you get the "Trust" part?

[tji]

Open Source CAs are pretty straightforward. All the code is available, and people are already doing it. The difficult part is establishing the trust model. The root CA needs to be well managed. But, more difficult is the process for issuing new certificates. If you just give cert's out without strong validation of who you're giving it to, your trust model is worthless. If anyone can go in and freely get a cert, what confidence do you have that the cert holder is not a "bad guy"?

That's why commercial CA's, like Verisign,cost money, and provide a real service. They do try to verify the organization they give cert's to. It may not be perfect,and many people complain about how strong that validation is. I can imagine what those people would think about an open source CA, and their level of validation before providing certs.

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)

YES! The government!

[bussdriver]

Certificate Authority:
secretaryofstate.state.us or departmentofcommerce.state.us
you should recognize who it is

Far more paperwork and verification is done to incorporate (business licenses.) They have to commit tougher crimes to sneak off with a corporation or LLC. You have multiple parties interested such as the IRS and secretary of state who look bad if dummy corps are floating around (you don't mess with the IRS gangsters.)

Certs allow for multiple signings if I'm remembering correctly. There is no reason freemarket freaks can't have their meaningless verisign certs or have verisign sign their government cert. There would still be a market for individuals and "high-end" additional verification but that would be just be for gullible people.

I've been saying this for a decade now. When will people come to their senses??
It wouldn't cost much. Local gov could source out the service for your irrational freemarket nuts.

My experience with government contractors:
1
politician X wants payoff for a friend
gov service is fattened up for the slaughter (sabotage or just talk)
politician X moves to kill
friend promises the world for half price and gets "special consideration" (for Bush skip this step)
friend doesn't meet obligations and/or goes over the bid (politicians in support cover their seat) ...
friend milks it for all its worth
Reformers kill contract or make it less profitable (friend moves to next city)
GOTO 1

Why some don't consider caCert open

[ChaseTec]

https://bugzilla.mozilla.org/show_bug.cgi?id=21524 3#c164

Pasting for those to lazy to follow the link.

Rich Freeman wrote:
>
> It just seems like as an organization we [The Mozilla Foundation]
> should be trying to foster open source projects.

Whoa, there. I'd just like to point out that CaCert is not an open source
project in any sense of the term. It uses open source software *internally* to
provide a free (as in beer) service, but CaCert distributes no free (as in
*freedom*) software, and no software that could even remotely be considered
open source. Just the opposite in fact, see the license here, on their site:
http://www.cacert.org/src-lic.php

It clearly states that you:
1. may NOT modify the source code [...]
2. may NOT make copies of the source code [...]
3. may NOT give, sell, loan, distribute, or transfer the source code files
to anyone else, an, my favorite:
4. may NOT use [CaCert] software created for any purpose or reason other than
verifying that there are no unknown vulnerabilities or the like or otherwise
making your own assessment of the integrity of the source code and the security
features of the CaCert software

Furthermore, below it goes on: "All rights not expressly granted to you
[editorial comment: which would be "none"] in these license terms are reserved
by CAcert. CaCert retains ownership of all copyrights and other intellectual
property rights throughout the world in the CAcert source code and software.
You agree that CAcert will be given a perpetual non-exclusive rights to any and
all derived code, and you hereby assign rights in any modifications you make to
the source code and in any bug reports you submit to CAcert."

This just may be the single most disgusting and ill-advised hybrid software
license I have ever read. The author apparently seeks to keep the software
100% proprietary, guarding it from "competitors", and protecting potential
future licensing revenue, while simultaneously benefiting from the efforts the
open source developer community to fix its bugs, and attest that it is not
malware, for free.

Although I wrote an impassioned comment (#12 above, of 161 so far!)
https://bugzilla.mozilla.org/show_bug.cgi?id=21524 3#c12 in *support* of
CaCaert, uh, 4 years ago now, and was a CaCert user and Assurer, I discontinued
my involvement because the source code was released by the founder only months
later, after much prompting and delay, and when it was finally unveiled, these
onerous licensing restrictions were "slipped in" with zero community
discussion.

When I asked why the code was not made open source, the founder described his
perceived threat that if it was made open source, then other free CA's would
start popping up out of nowhere to run our code and to compete with CaCert and
he felt that this would decrease CaCert's chances of getting its root cert into
Mozilla, and then IE.

This seemed a paranoid and protectionist attitude and I've no longer
participated in the Assurer program or the CaCert community since, though I
have monitored the mailing lists. After the founder's recently announced
resignation, perhaps the new board of directors (or whatever governing body
structure they adopt) will revisit this anti-competitive, closed source
position.

I had though a free CA would be a good thing, and if one is good, then two is
better, and hundred would be fantastic! So if they all *do* pop up, and share
code and development effort, I believe that all will benefit and perhaps,
someday, all will be accepted by all the browsers, and Verisign and the sma

Re:What's

[Workaphobia]

None. The card's just an artifact of the past. Under the current system even, there's no reason to have a card in internet shopping if you have your number and security code written down on a piece of paper.

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

This is idiotic

[wasabii]

The entire idea of these companies is that they present a publicly viewable, *SUE-ABLE* name to ensure a path to the company applying for the certificate. An "open ca" would be utterly useless in accomplishing this.

The idea is that verisign and pals spend a non-zero amount of time verifying you are who you say you are. Such a non-zero amount of time costs money. Hence the certificate costs money. Whether it is priced right or not is driven only by demand and production. Deal with it, or make your own.

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

PGP != CA

[DrYak]

That's two different thing :

PGP (and GPG) are systems using public/private key pairs. They are used to encrypt/decrypt or sign data from one point to another in a transmission.
The thing that you are sure is that given one public key, only the corresponding private key in the pair could process the data in the opposite direction. (Completely independent of where that other key is).

CA are certificate. They certify that the person using a given key IS a person with characteristics specified in the certificate. For example, a CACert certificate always certifies that a given key was issued to some specific e-mail (and if you follow the correct procedure, you could also certify other verifiable informations like you name, etc.)
The thing you are (somewhat) sure is who the person with the other key is supposed to be.

PGP are about making key pairs, CA are about knowing who is (supposed to be) who.

The current problem is that, with most current application, you can only use keys issued by CA's for web site, mail servers and similar, and you have only 4 options : 3 of them being the 3 listed companies, the 4th being being your own CA and signing and certifying your own keys yourself (but in that case, it's difficult to trust the signing because no browser has a corresponding CA key to check your CA certificate. Whereas keys issued from Thawte, Comodo and CACert could be checked against the their key that a browser comes with)

Re:Very Large Prime Numbers

[Zeinfeld]

Better yet, generate the keys on a smart card so that the private key can't be extracted or exported by code on your computer. Do you really trust your OS? With a smart card, the signing occurs on the card and not in your computer. This improves the system security at a much lower cost than doing the signing in a special crypto hardware module.

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.

Re:Great idea

[Beryllium Sphere(tm)]

And after you investigate and find a reliable plumber, you don't want to have an impostor show up with a big wrench and an invoice pad.

This isn't much of an issue in meatspace, but on the Internet the work you did to determine whether a business is acceptably safe is wasted if you end up at a typo squatter's site.

The value of a third-party certificate, limited by the relatively weak checking and the fact that virtually no customers understand it, is that although anyone could register bofa.com and be impossible to catch, if you see a cert then you can look at the DN and know where to send a process server if something goes wrong. In principle, certs from CAs provide the mapping from a public key to meatspace identity that allows you to transfer your offline knowledge to online transactions.

The other thing that limits the value is that CAs aren't offering nice fat sums of money to reimburse anyone who gets fooled by https://www.paipal.com./

This should all have been connected to trademarks in the first place. Trademark law has been sorting out impersonation and confusion for centuries. Certs should attest to a trademarked logo, CAs should check the trademark registry or other documentation.

Re:Great idea

[fyngyrz]

but on the Internet the work you did to determine whether a business is acceptably safe is wasted if you end up at a typo squatter's site.

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.

limited by the relatively weak checking and the fact that virtually no customers understand it

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

if you see a cert then you can look at the DN and know where to send a process server if something goes wrong

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.

In principle, certs from CAs provide the mapping from a public key to meatspace identity

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.