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

Great idea

[Anonymous Coward]

That's a fantastic idea! Why don't you pay for setting up and running the whole company, then I'll go and use it! Oh and while your at it, can't you set up open source supermarkets too?

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

Re:Great idea

[vagabond_gr]

Oh and while your at it, can't you set up open source supermarkets too?

Better make it web 2.0 too.

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.

Re:Great idea

[dkf]

You seem to be confused. Though self-signed certificates are fine enough for testing, they have a problem when you try to use them for securing real communications over the 'net. The problem? The bad guys can create them too, making it possible for them to do a "perfect" attack on the website (with the help of a bit of DNS attacking). That would be Bad. I really think that being able to have an encrypted conversation with scum isn't a big step forward. The only way around this is to have a third party, trusted by your client software, that verifies that a certificate is actually for what it claims to be. That's what the standard web PKI system does. Add in something like CRLs or OCSP and you can even remove most of the technical weaknesses in the PKI system that you've spotted.

But there are a number of other issues. Firstly, certificates have other uses than securing communications with websites (notably signing and/or encrypting documents or code) which have other vulnerability profiles. Secondly, PKI currently only really talks about identity; nothing is said about what that identity assertion means, and that's quite different from how identity is typically managed in meatspace. Both of those points hinge on trust; what we've got are identity assertions, but what we're after are trust assertions. Thus, on the first point I suspect that webs-of-trust built on top of PKI will be the best approach, and on the second I feel that there's much work still to be done, with a key part of the process being when the certificate signing bodies take proper legal responsibility for their actions; for example, if GoDaddy were to sign off on something that was part of a deceitful trademark infringement and I was to get scammed because of it, I should have recourse against GoDaddy as well as the scammers. There are probably other things that need doing, many of which may not be technical but rather regulatory; a tech fix isn't always the best solution.

Re:Great idea

[fyngyrz]

Though self-signed certificates are fine enough for testing, they have a problem when you try to use them for securing real communications over the 'net. The problem? The bad guys can create them too

The bad guys can create certificates from the certificate authorities too. This in turn creates a situation where the only actual use for certificates is encryption. Unless you can come up with a plan that actually prevents the bad guys from getting certificates from the CA's while at the same time not coming up with Verisign-like prices where the smaller vendors are locked out, your ideas don't have any merit.

There is no identity service provided. You can't demonstrate one because it isn't technically possible with any part of the system in place. Nothing tracks where the certificate holder is post-purchase, and with location goes accountability. It's a scam. Encryption is all there is, and for that, self-signed certificates are just as effective as a CA certificate, plus they are free. The only "problem" they have is that browsers will have a fit if they encounter one; that's a browser problem, and it can be fixed by the browser manufacturers in moments if they can think their way out of their complicity in this scam.

Re:Great idea

[bogado]

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.

the 'typo' example is a bad one, the problem is that for many reasons the site you are seeing may not be owned by the same person that bought the original certificate. That is why you have to trace it back to the origin, to make sure that the site I am seeing is owned by the person/organization that I trust.

If anyone can do a perfectly good self signed certificate then every certificate is as good as anyone's else and there is no way to be sure of who I am talking to on the other end.

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

The problem is that security is hard, much harder that people are likely to try to understand. Well you see creating a cryptographic channel between your computer and the server is the easy part, and that is what the browser is doing and indicating to user by the little lock. The problem that encription alone is not enough, as you have said, anyone can do it, so if I can fool you into using my certificate instead of the original one, say I have poison your ISP DNS server for instance, I could set up a proxy (man in the middle attack) and serve the exact same page that you're expecting to see but this time I get to see everything.

What make this impossible to happen now? Well if the system worked as designed, this would be impossible, because the certification authority would not grant me a valid certificate for a site that belongs to another person. So the best I can do is to self sign, or to create a dummy cert-authority to sign my version, and the browser will send a warning.

The real problem is that people are willing to accept invalid certs, self signed certs, and will press ok to any warning pop up that they see on their browser. In fact if you use no encryption at all and put a lockpad somewhere in your page it is a good bet that some users will accept this page as secure.

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

Re:Great idea

[fyngyrz]

the problem is that for many reasons the site you are seeing may not be owned by the same person that bought the original certificate. That is why you have to trace it back to the origin, to make sure that the site I am seeing is owned by the person/organization that I trust.

You cannot trace it back. If the cert says it is for goodmerchant.com, and Leroy Trustworthy owns it, at 351 Oh-So-Honest Blvd, and that's the address on the web page, the cert and the site match. Is it really Leroy Trustworthy? Or is it the guy who SAID he was? Or is it the guy who stole Leroy's computer? Are they at Oh-So-Honest blvd, or are they really at My-Physical-Mail-Bounces-Emptylot, with a phone that answers "No one is available to take your call, but you are important to us..."? How does the certificate help, in any way, to make the distinction? Especially in such a way that the consumer can "trust" the site because it simply has such a cert? Go ahead, think those over. I'll watch the thread for a few days.

[a] If anyone can do a perfectly good self signed certificate then every certificate is as good as anyone's else and
[b] there is no way to be sure of who I am talking to on the other end.

[a] Yes they could, and [b] yes, there is no way to be sure, but the only difference between that state you imagine there and the current state is that the only "good" certificates at present are those that the browser won't trigger on and scare the consumer away. Currently, there is no way to be sure of who you are talking to on the other end *right now*. If you think otherwise, see the previous paragraph of this post.

The problem that encription alone is not enough, as you have said, anyone can do it, so if I can fool you into using my certificate instead of the original one, say I have poison your ISP DNS server for instance, I could set up a proxy (man in the middle attack) and serve the exact same page that you're expecting to see but this time I get to see everything.

Encryption, however, is all we have. Everything else is a detriment. You can be attacked. Right now. You can get many site's certificates through straight hacking; Windows machines are pretty easy, and you can even take down an awful lot of linux servers by uploading a race hack that escalates into root privileges, and then simply running off with the certificate. The security minded here know exactly what I'm talking about. You can do it by walking up to an unsecured console on a Windows machine. You can get the certificate at gunpoint, or by bribery. Hacking a DNS might be harder, might be easier. The guy in the store you're used to going into might have killed the owner, who is lying in the back room, and is going to happily walk out with your money the minute you leave with order placed. All of this aside, someone can grab a cert that looks perfectly reasonable (amazon.ecom.merch.com), attack the DNS, redirect you to that site, and you'll happily give them your credit card. All these things are possible, and certificates don't protect against them at all. They are a scam.

Well if the system worked as designed, this would be impossible, because the certification authority would not grant me a valid certificate for a site that belongs to another person.

The certificate authority has no way to know if the customer is interacting with a legitimate merchant. Because you can BE legitimate right up until the second you get the cert, and then embark on an ecommerce rampage that lasts years, until the certificate expires. The slicker you are, the more you'll get away with, but in no case will anything the CA does slow you down, and in no case did anything the CA did help the consumer. Quite the opposite: The (completely uninformed and not related to the facts) implication that the merchant is legitimate and is located somewhere speci

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 .

[tomz16]

Your scheme is brilliant because :
- Credit card companies have an infinite supply of employees and money to authorize me every time I need to use my card to buy a 99 cent pack of gum without subjecting me to a 20 minute wait time.
- I have an infinite supply of time to wait for said authorization.

In the past few months I have actually found that several retailers have RELAXED their signature requirements on credit card purchases. Many stores now no longer require a signature below a certain amount. (IIRC My local home depot is now $50). Incidentally, I am liable for the first $50 in unauthorized purchases... hmmm...

Re:Zimmerman has it right .

[bahwi]

They seem to have infinite employees calling me to add new services to my card that are expensive, overpriced, difficult to cancel "protections" that I'm ultimately ineligible for.

"You really should have it and be paying for it now in case you ever become eligible for the benefits and then lose your job!" WTF? (by ineligible I mean I'm self employed so not eligible at all under most of their crap).

Re:Zimmerman has it right .

[Monkeybaister]

All systems will depend on a "stupid number". The credit card system is broken because it relies on a shared number. It should instead work like a smart card where the number is pretty much (not absolutely) unobtainable, and then do a challenge-response based authentication between the credit company and the card to authorize the purchase (which unlike what some other poster thinks, would only require computers, humans would be too likely to screw up the numbers). Another addition would be to have a keypad on the card to input a pin number to activate the card.

There is an extreme amount of misplaced trust in so many systems these days. Don't trust the network, don't trust the terminal, don't trust the holder (not necessarily the proper owner) of the card.

This is why I don't want an RFID credit card, it's still based off a security broken system.

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 .

[Workaphobia]

Well making it not a shared number is one solution, but not the system I was getting at. In my version, the shared/stupid number would simply be used for identification. Possession of this number does not amount to authorization, nor does it have to be kept confidential. You simply need a different means of securing the channels between the cardholder and credit company, and the merchant and credit company. Let the sensitive information be internal to the credit company.

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 .

[leonmergen]

Let's say that Visa launched a new line of credit cards, call it 'Visa Net Secure' or something: they could provide a web-interface for allowing or declining transactions, in which detailed information about the transaction (and more importantly, the company conducting the transaction) is available. You can set certain companies to 'trusted', whose transactions are automatically accepted. And to fix your 99 cent problem, you can just as well use that 'accept transactions below a certain threshold' idea there too.

Heck, they could even make it so that you receive an email every time a transaction to your card occurs, so you don't have to proactively check for transactions. If only such a card existed.. :-)

.. oh yeah, they should make their interface web-2.0 compliant too with rss feeds and funky javascript.

Re:Zimmerman has it right .

[Anonymous Coward]

Actually.... I wouldn't mind a secure RSS feed of my posted transactions...

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 .

[tomz16]

So let me get this straight. I go through the checkout line, I swipe my card, sign the authorization slip, and then whip out my internet connected PDA / cell phone / laptop to authorize the transaction before the merchant gets their payment confirmation and I can walk out of the store.

Brilliant... except for all of the obvious flaws...

Citibank can already send me daily alerts on my current account balance. Anything more is superfluous as my liability is only limited to $50 of unauthorized purchases made on my credit card. Chances are that limit will be reached the FIRST time some miscreant uses my card.

I think the current system works very well. But if you want a simple, quick, low-tech method for accomplishing much more for much less... REQUIRE a picture on every single credit card (POS transactions), and be strict about the requirement on merchants to ship ONLY to addresses on file (online/telephone 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 .

[bratgitarre]

You're actually interested in whether this Ckwop guy I'm speaking to now is the same guy as I spoke to last-time. But you still should be able to find out who Ckwop is if you need to sue him/her.

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. :)

Re:Zimmerman has it right .

[shaitand]

'REQUIRE a picture on every single credit card (POS transactions), and be strict about the requirement on merchants to ship ONLY to addresses on file (online/telephone transactions).'

The picture sounds good. The changing card number idea is great. The only ship to billing address idea is terrible. It is inconvient and annoying when something you need NOW is declined because you live in a 'city' within greater Miami and told the card company the city name and put in Miami on the other. Or when you *gasp* want something shipped somewhere besides where the bill goes. Maybe, just maybe, you don't want to be harassed by card companies and don't use your real location and contact information, instead using a answering machine for that line and a drop box. All that is forgetting gift purchases of course. I even travel back and forth between two states and have a number of addresses in each state where I want things sent. Since my credit card company lets me give them one billing address and paypalers will only ship to your verified address and ignore all your others it is enough to drive a man insane.

Changing numbers would be great if they don't give the vendor a way to tell the difference. If they do, vendors will refuse. Even legitimate vendors because they all want automatic subscription renewals.

* This post has been paid for by violent men with large weapons.

Re:Zimmerman has it right .

[Old Wolf]

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.

But then Catherine Zeta-Jones can't use her Visa to buy bananas off monkeys!

Re:Zimmerman has it right .

[Wesley Felter]

SET failed, and now we have Verified by VISA, which I refuse to sign up for because it imposes extra work on me for no benefit. I'm not eager to try this idea a third time.

Re:Zimmerman has it right .

[Monkeybaister]

Well, you glossed over an important point: how is your system going to check for authorization?

You have to contact the credit card company and they'll have to confirm that you are who you say you are, which would rely on password/smartcard/biometric. Guess what, those are all numbers! That's what happens when something is digitized, it becomes numbers.

So the credit card holder must know something that amounts to a number in computer terms, so there is always sensitive information external to the credit card company.

Re:Zimmerman has it right .

[StormReaver]

"...there are presumably fewer security checks that the person requesting the certificate is who he says he is."

When I setup my employer's online payment system, I went to VeriSign's site (which I opposed, but I was overruled) and signed up for a certificate. I got a call from VeriSign that went something like this:

VeriSign: Are you the person who requested a certificate?
Me: Yes.
VeriSign: Send us the money and we'll email your certificate to you.

The certificate arrived in unencrypted email! I kid you not.

That was hardly inspiring security. Considering that anyone who was eaves dropping on our unencrypted email traffic could have intercepted our certificate at the source, identity verification via CA's is next to worthless. Certificate Authorities are just con artists preying on people's fears.

The only thing a certificate is actually good for is to ensure that traffic between Point A and Point B is being encrypted sufficiently well to be meaningless to anyone who intercepts it. For that, a VeriSign certificate is no better than a self-signed certificate. I would prefer a self-signed certificate, because then at least it isn't susceptible to interception before implementation.

Re:Zimmerman has it right .

[zantolak]

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.

Or they think encryption should be available for all HTTP traffic instead of forcing people to pay hundreds of dollars to these "authority" rackets for something functionally equivalent and just as secure as a self-signed certificate, just so the end user's browser doesn't pop up a warning because they dared to use a certificate that isn't from a company that managed to convince browser manufacturers that they're somehow more worthy of being trusted. Certificate authorities are a scam, plain and simple. Encryption needs to be freely available for everyone, not just people willing to shell out an extra $100-400 a year for something they could do themselves.

Re:Zimmerman has it right .

[Kalriath]

Sorry, you're not quite correct there. For a start, what you don't realise is that Verisign completely ignored the phone number you provided on the application. They took your company name, and looked it up against what they consider a trusted source (usually your telco's white pages), calling THAT number. Next, the certificate they sent you is next to worthless. It does not contain your private key, only your public key (your private key was installed on your PC when you filled in the forms in the first place). It certainly doesn't need to be encrypted, considering how useless it is on it's own.

Re:Zimmerman has it right .

[bcrowell]

Or they think encryption should be available for all HTTP traffic instead of forcing people to pay hundreds of dollars to these "authority" rackets for something functionally equivalent and just as secure as a self-signed certificate
No, it's not functionally equivalent. The CA is supposed to verify that you really are who you say you are.

Re:Zimmerman has it right .

[Workaphobia]

Lemme clarify: When I use the term stupid number, I'm referring to a number that is more vital to and trusted by the system than it should be. For example, social security numbers are under this definition stupid numbers because they are used both for identification and authentication, and can cause far too much damage once they are compromised, which is easy because they are so widely shared. Credit card numbers are in a similar boat, because possession of the widely used number is assumed to indicate authorization. I have nothing against numbers or cryptography in general.

The system I was alluding to would have the buyer give a semi-public identification number to the merchant, who would then use it to obtain money from the credit card company, but only after the user authorized the payment by logging in to their online site through a means that is at least as reliable and secure as the best internet consumer business transactions today.

Or you could eliminate the shared number aspect altogether as you suggested earlier, replacing it with one time use tokens that the customer holds on to and exhausts one by one, each of them set at various maximum expenditure thresholds. Of course then you have to safeguard this book of tokens from physical theft, perhaps by supplementing it with a password system, but then we're back to using the credit card company's site and phishing attacks.

Whatever, there are plenty of ways to fix the system, because it's near impossible to make any changes to what we have now and make it worse.

Re:Zimmerman has it right .

[Zeinfeld]

Credit cards simply should not work based on knowledge of a stupid number.

Few people would argue with that idea.

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.

That is underway, in Europe they already use smartcards for credit card transactions. Getting that to happen in the US is a major problem because there are 10,000 issuing banks and the cost/benefits of smartcards do not fit into the existing model.

Even so it is going to take a very long time for the old card number system to disappear.

Re:Zimmerman has it right .

[Zeinfeld]

The certificate arrived in unencrypted email! I kid you not.

And worse still it is sitting in an LDAP directory with world read access.

The certificate is a public document. The security of the system only depends on keeping the private key confidential. The certificate is transmitted in plaintext in pretty much every mainstream protocol.

That is what Public Key Cryptography is all about.

The point of the verification callback is to check that the person who applied for the certificate was authorized to do so. What you did not see there is the checking that went into finding the number to call you on.

Re:Zimmerman has it right .

[owlstead]

"1: # Nobody actually reads the certificates."

Actually, I do, and it only takes one person to catch a bad certificate.

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

Not too difficult. There is some checking if you are a real person, so they may be able to track you down, and you need to pay some money. I won't get one for "betalen.rabobank.nl" though, which is my banking site. They probably would check if the domain has already been taken, or check against each other databases.

"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 doubt I would get a certificate for betalen.rab0bank.nl. But if I could, and nobody would spot it and I used fake credentials, I might be able to do some phishing. I don't think it would take too much time for the scam to be found, and I do think that there would be a *lot* of attention given to this attack.

Of course, if you would take over the computer of some poor sod, you don't need all this certificate stuff anyway, just insert your own root certificate and create your own trust.

Re:Zimmerman has it right .

[Anonymous Coward]

• Banking authorities CA`s
  
• A Consumer advocacy group CA

This could allow for more meaningful signing policies. Perhaps even including basic security checks. If a bank doesn`t fix its cross site scripting problems its cert expires. Got caught loosing one to many backup tapes with customer details? Back to verisign for you!

And as far as conflicts of interests go, I would say selling both wholesale snooping/surveillance equipment *and* certificates would be one of the bigger ones. Putting the verisign root keys in a snooping system would create a killer MITM snooping system. No competition could match it. Great for all those that could afford it.

Someone in some marketing department should have though a little more before putting out these press releases. Verisign could at least try to conceal this product combination by selling the snooping hardware under some other name. Not understanding this problem shows it doesn`t understand the business it is in. Hint: Its not renewing certificates, its selling trust.

Verisign also signed code signing certificates for "Microsoft" to someone other than Microsoft. At some point one has to reconsider having the verisign root cert trusted by your browser and mail clients.
And that is on top of corrupting the hell out of its ICANN relation and the sitefinder drama.

Re:Zimmerman has it right .

[Anonymous Coward]

To add to what the other guys said -

If you really don't understand this stuff and don't understand that you need to keep the generated private key safe (which you seem not to realise you have!) then you were absolutely the wrong man for this job. Let's hope you didn't leave an easy attack vector on your employer's secure site through your incompetence.

Re:Zimmerman has it right .

[Anonymous Coward]

"...and your done." You need to learn the difference between your and you're. "You're" is a contraction for "you are" so I think "...and you're done" is what you wanted. "Your" is possessive. Example

You're coming across as an idiot because of your grammar.

Re:Zimmerman has it right .

[Anonymous Coward]

SSH stinks for this reason. Everyone should be using SRP.

Re:Zimmerman has it right .

[mikael]

'REQUIRE a picture on every single credit card (POS transactions), and be strict about the requirement on merchants to ship ONLY to addresses on file (online/telephone transactions).'

Or you're a student and want your credit card bills to go to your normal home address (parent's home, which may even be in a different/state/province/country) while you want stuff delivered to your term-time address (work or home).

Re:Zimmerman has it right .

[zantolak]

Encryption doesn't have to be conflated with authentication. You don't need to prove who you are to secure your server's communications with clients.

Re:Zimmerman has it right .

[walt-sjc]

Just a FYI, credit card companies allow you to specify an alternate address for EXACTLY this purpose. Many eRetailers *already* require that the credit card company have the shipping address on file.

If you want to come up with a scenario that is real, try ordering a part to be drop-shipped to a customer site. That's a case where the ccard company will never have the shipping address on file. In that case, you just have to have a good trust relationship with a vendor to bypass the requirement.

This is NOT a credit card company requirement, and probably will NEVER be a credit card company requirement. Why? Because credit card companies are not liable for fraud - MERCHANTS are.

Re:Zimmerman has it right .

[Anonymous Coward]

You're actually interested in whether this Ckwop guy I'm speaking to now is the same guy as I spoke to last-time.

OK. Existing cert mechanisms could let you do that. The trouble is that, whether you use certs or some other mechanism, it's quite difficult to keep track of the huge number of people/sites that you want to trust.

Think of ssh, for example. If you configure it to do so, it will prompt you every time a new host is seen, and ask you if it should be added to your list of trusted hosts. Imagine doing this for every web site you'd like to trust. First - how do you trust them the first time? Second - how do you reasonably keep track of whether you've seen this site before? Maybe you can remember that you shouldn't see a "this is a new host" message when you visit Amazon because you go there so often. But are you going to remember whether or not you've previously accepted a cert from third-party-vendor-xyz that you're doing business with? Probably not.

The big problem with the current browser cert situation is that it's strictly hierarchical. A web of trust model would be much more effective - and more open to boot. The trouble with that solution is that even a lot of tech people just don't "get it", nevermind grandma.

Re:Zimmerman has it right .

[bcrowell]

Encryption doesn't have to be conflated with authentication. You don't need to prove who you are to secure your server's communications with clients.
Agreed. That's what this whole thread is about.

Re:Zimmerman has it right .

[X0563511]

Verified by VISA isn't even enforced. The merchant has to participate, which is so uncommon that I eventually gave up and removed it from my accounts.

Re:Zimmerman has it right .

[the_womble]

There are credit cards that do the web based interface bit of that.

As part of every transaction you are redirected to the issuer's website to confirm the transaction there.

The problem is that it now introduces another thing to forget: one more password.

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.

Re:In reality...

[DrSkwid]

When I connect to my mail via SSL on a public network, I want to have a means of 1) verifying the endpoints and 2) encrypting the traffic.

Knowing that you're connected to company.com *is* a big deal because you're about to send your some sensitive info.

Re:In reality...

[J'raxis]

A certificate being issued by the secretary of state to a corporation upon incorporating does not necessarily preclude private businesses such as VeriSign from continuing to sell certificates to other entities. But rolling SSL certificates into the incorporation process would mean a business could get certs for no additional cost.

Perhaps a more meaningful place to "bundle" SSL certs, however, would be at domain registration, since the relationship between business name and domain name(s) might not exactly be one-to-one mapping. How about a domain registrar that offers a wildcard cert along with each domain registration?

Re:In reality...

[tomstdenis]

You can exchange certs in more meaningful fashions than having verisign hand you a cert.

But again, so what? What does that mean? So you know you're talking to company.com, should you trust them?

Think of it from the business point of view. I google for "evil dead figurines" and find some store [making it up] called badashstore.com. It has a valid certificate and all that jazz. Should I buy from them?

Tom

Re:In reality...

[DrSkwid]

1) Certificates are used for more than https
2) You're confusing the levels of trust. You can now trust that snoopers on the network you are on are not party to your conversations with badashstore.com and that the DNS entry they supplied you with was the one assigned to that certificate.

You then have roughly the same trust level as paying for your meal in a foreign city with your credit card.

If you subsequently trust them by their actions you then have a mechanism to know you are talking to the same entity.

I think all of those things are worthwhile.

Re:In reality...

[tomstdenis]

Point is, I'd trust a cert more if I knew it had the businesses license #, contact info, etc. Then if I get screwed by them I could go after them. The two problems against that is that businesses are all over the legal roadmap [e.g. not all in one jurisdiction], and there is no legal requirement for certs to contain meaningful information.

Strictly speaking DNS doesn't matter, that is, so long as the real entity doesn't give out their private cert. If you redirect me from the store to your website, and try to pass off a fake cert, the browser will warn me and I won't use the site.

Tom

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.

Re:Advertise it for other than e-commerce.

[crush]

I don't really understand what the original poster meant by saying CACert is not open source.

Well this is the license, and it seems to not allow us to modify and redistribute the source.

Re:Advertise it for other than e-commerce.

[TheRaven64]

I hadn't seen that, but now that I have, I am still not convinced it matters. It's like asking if we need an open source search engine. Whether the CA uses open source software or not makes no difference. We aren't lacking open source software to allow people to run their own CA (it comes with OpenSSL, found on most *NIX systems). The software used by a CA is completely irrelevant to the service it provides, which is a method of verifying someone's identity.

A completely open source CA would allow redistribution of everything, including their private root key. If they did this, then their signing service would be completely pointless, and no one would use it. If CACert switched to using OpenSSL (actually, I've no idea why they don't; I thought they did) then it wouldn't affect the service they offer one bit. Similarly, Verisign could become an 'open source CA' by using OpenSSL, but I still wouldn't want to do business with them.

Re:Advertise it for other than e-commerce.

[crush]

I'd agree with you completely, but that's where the objection comes from.

Re:Advertise it for other than e-commerce.

[Anonymous Coward]

Let's be clear here. IE doesn't itself have a certificate store. ~Microsoft~ requires that any CA that wants to go in the Windows root store undergo an audit which proves that they've done proper due diligence. Microsoft doesn't get paid at any point during this transaction.

Re:Advertise it for other than e-commerce.

[Zeinfeld]

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.

Microsoft no longer charge for including a root. Instead they require a CA to have a WebTrust audit. That can run to a hundred thousand dollars.

The issue that keeps comming up here is that people want to do encryption without a CA. Thats fine, the CA infrastructure was designed to support authentication, not encryption. If you are not concerned about a man in the middle attack you do not need a CA.

What you do need a CA for is to cause the padlock icon to be shown to the user. And in todays browsers that happens with every SSL session. The solution that I proposed a couple of weeks ago is to support encryption-only SSL in the browser. You would still have issues with legacy browsers but that will solve itself in 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?

Re:What is the question?

[StartCom]

The real issue with a CA isn't about some source code for the issuing of certificates. There are many open source solutions for that like OpenCA and others. The issue is about policies and practices, how the organization performs and who takes responsibility. Much more to add here...

Re:What is the question?

[SiliconEntity]

I agree with the comment that the real issue is what it means for a service to be "open source". There are a couple of features you might look for. One is transparency. Open source code gives visibility into what it will do in a way that closed source cannot. For a service, this would mean some mechanism to make sure that the service will do what it claims to do. Another feature is malleability. With open source code you can alter and tweak its behavior to suit your needs. For a service, probably the closest you could get would be the ability to set up your own copy of the service that works in a slightly different way.

One approach to transparency is the concept of a Transparent Server, which is designed to allow remote verification of its policies and procedures via Trusted Computing technology. (It actually is a reversal of the normal Trusted Computing concept, allowing clients to verify servers rather than vice versa.) However this can only go so far when dealing with something like a Certificate Authority, where ultimately human decision making authority must come into play in deciding whether a threshold of authentication has been reached to authorize issuing a given certificate. Unless your CA is completely automated and would, for example, issue certs merely on the basis of an email auto-response, or perhaps using a web service interface to query Dun and Bradstreet, you're not going to be able to verify its policies remotely even if you can check what code base the server is running.

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.

Re:Root certificate inclusion is expensive

[igny]

I thought that FAQ was pronounced close to fuck, so it should be a FAQ, not anFAQ.

Re:Root certificate inclusion is expensive

[Macfox]

I followed this thread, while becoming an assurer for CA cert.
Long read, but worth it to understand the complexities in getting "trusted".

Essentailly theres a lot of hoops to jump through and at 1st glance seems excessive. But in reality it's necessary to keep the system from becoming redundant.

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

Re:Root certificate inclusion is expensive

[Anonymous Coward]

That's obscene. Maybe that's the problem that needs to be addressed, first and foremost.

Re:Root certificate inclusion is expensive

[MooUK]

Not if you would read it as "an eff ay cue", which is what I would do. For acronyms, unless the acronym is usually used as a spoken word rather than individual letters, you go by the sound of the first letter. Examples: "A BBC program", "An EFF Lawyer", "An NDA", etc etc.

Re:Root certificate inclusion is expensive

[Anonymous Coward]

I've frequently the use of a/an depend on what the first word actually is. For example, in "NDA" it's "a NDA" because it's "a non-disclosure agreement".

So, in other words, you expand the acronym to determine what the preceeding word would be.

Re:Root certificate inclusion is expensive

[StartCom]

CAcert will NOT be in Mozilla at any time soon! At least not until they comply to the Mozilla CA policy. Try StartCom instead.

Re:Root certificate inclusion is expensive

[MooUK]

I can see your reasoning. However, if you were reading "an NDA" or "a NDA", you wouldn't necessarily read it in full. The written form should be related to how you would read it exactly as written.

(Also, I think you missed a word or two at the beginning. Probably adjusted.)

Re:Root certificate inclusion is expensive

[leenks]

It depends. Do you say "a FAQ" (fack) or "an F A Q" (eff ahy cue)?

Re:Root certificate inclusion is expensive

[shaitand]

There are exceptions in the realm of common usage but as a general rule it is improper grammar to pronounce acronyms, you should always say the letters.

I once went to an interview for a systems administration position with a large hosting company. Naturally, this position would involved administrating a Linux cluster farm and there were dozens of acronyms required to get the job. The guy doing the interviewing was familiar enough with the technology to know what to ask but he pronounced every acronym. His pronunciations were so bad I didn't figure out what had happened until after the interview, up to that point I thought they just used lots of niche proprietary stuff.

The whole interview went much like this:

Interviewer "Are you intimately familiar with enphus?" (I later determined this must have been NFS)
Me "No, as a rule I only implement standard technologies and use open or in-house solutions to fill the gaps where needed."

Re:Root certificate inclusion is expensive

[Anonymous Coward]

...as a general rule it is improper grammar to pronounce acronyms

Well, in its strictest meaning, acronym, by definition, is pronounced as a word. "Acronyms" which aren't pronounceable as words are technically initialisms, though the term acronym has had its meaning broadened by common usage.

So, if an initialism is also an acronym (common examples, SCUBA, AIDS) in the strictest sense, it should be pronounced. Otherwise, the letters should be spoken.

Re:Root certificate inclusion is expensive

[Anonymous Coward]

"An" is used in front of vowels and the letter "h", "a" is used in front of all other consonants. That was what I was taught in English. Do you have different rules for this in the US as opposed to the UK or were you just not taught this?

Since FAQ starts with a "F" it should be preceded by "a" not "an".

Re:Root certificate inclusion is expensive

[MooUK]

I *AM* in the UK. And it is based on sound, not actual letter. "An historical record" is ONLY correct if you use a silent h.

Re:Root certificate inclusion is expensive

[Vintermann]

Do you know any nayfus? how about sassel then? veepun? xemmel? essoaype? tech? laytech? eyebeam software? emmys?

Re:Root certificate inclusion is expensive

[Abcd1234]

Your English teach was an idiot. "An" is used before words with a vowal sound, to aid in pronounciation. "Eff" starts with a vowel sound, therefore F-A-Q (when pronounced) should be preceeded with "An".

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

[sjwest]

I agree - I roll my own ca's here

So firefox informs me that when i do open https:/// its flaggable and that seems WAY more secure to me than having a ca signed by some company that by default i have to trust and may be 'wrong'.

Since no insurance company will probably ever payout on an an illegal ca (thats becomes fraud and criminal matter) i don't see the point the thwaite et al. Mind you they could not even be bothered to even send me an electronic pdf when i once asked them for information once.

Sounds good - but in practice root certs seem useless 'trust' I would recommend everybody does there own ca cert auth.

Re:Certificates are a scam

[DraconPern]

Push it out via active directory. I did it with an startcom free ssl.

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.

Re:Certificates are a scam

[duffbeer703]

The certificate system isn't completely usesless -- There's a paper trail linking a certificate to a bank/credit card account.

If someone buys a certificate, you can conduct an investigation and trace it back to the person who made the purchase, and from there to the authorizaer. If you buy some sort of Verisign cert with a stolen credit card, they'll revoke the cert once the chargeback comes through the CC.

An open-source CA doesn't make sense, as you cannot enforce the security standards.

Re:Certificates are a scam

[Gwala]

Protip: Self-Signed Certificates are worthless.

Hypothetical: I hijack your DNS and point your servers IP at my faux-server. For this example, I'll call those 'original', and 'fake'.

You have a self signed certificated issued to by . Since I now control that domain, I can issue a certificate with those same details to myself. Because it's being issued by the same authority, there's no steps required to take those names or assumptions.

This same attack can be performed using a man-in-the-middle on the connection establishment (eg a proxy).

Certificate Authorities avoid this attack since there's more than just the name involved - the certificates themselves are signed all the way back to the root which the browser has a copy of and can verify.

They may be ridiculously expensive, but most professional certificates usually involve a degree of identity verification - this can be as little as confirming that the phone number you provided is accurate (at the low end), to recieving copies of articles of incorporation and full on background checks.

Re:Certificates are a scam

[Jeff DeMaagd]

It's even more than that, it links a certain IP address (you have to have a fixed IP), a certain registered domain to a specific business bank account. And in many places, you can't get that bank account without at least registering with a local bank. A typo domain spoof of a secure domain is possible, but I question why someone would go to that length. Getting registered also means that you get into the browser by default. If the browser spits out a nasty warning, a lot of users would go away, so any solution where the user has to manually add anything is probably going to cost money in lost sales.

I do agree that the cost is a bit much, $100/yr last I checked, but if you sell stuff, going with the free solution can easily cost more that that in a week's or a day's worth of lost business. You are probably better off either getting it if you maintain your own store software, or just using a reputable store services.

Re:Certificates are a scam

[c0d3h4x0r]

How can Thwarte or Verisign or whatever be at the root of a "web of trust"? Trust from whom. Not from me.

That is indeed the fundamental problem with SSL-type usage of certificates. Most visitors to a web site don't even know who or what "VeriSign" or a "Certificate Authority" is. When they get a pop-up from their browser saying a CA is unrecognized or a certificate has been revoked, most web surfers just proceed anyway because they don't understand what it means and don't care.

What is needed is a better integration between the human concept of "trust", the web brower's UI, and the technical implementation of security. "Trustworthiness" is something users should (and do) decide for themselves, not something that users believe blindly on the word of some company like VeriSign.

A better system would be if every web surfer and every web site had a "collective trust score", calculated from individual web surfers' votes. The "collective trust score" would be a weighted average computed such that the votes provided by more trustworthy web surfers counted more. That way, if some user goes around upvoting untrustworthy sites, the community can vote that user's trustworthiness down so that their tactics have little influence on the site scores.

My browser's UI (via a plug-in or otherwise) would automatically show me the "collective trust score" for every site I visited, and give me the opportunity to rank the site myself. Furthermore, I could drill down and do meta-voting things like "for all users who ranked this site above 8 on the 10-point ranking scale, rank their trustworthiness as 0", or "rank user Superbob347 as a perfect 10 on the trustworthiness scale (perhaps because I personally know and trust him)".

This isn't exactly "open source" (whatever that means in the context of security architecture), and it isn't exactly bullet-proof security, but it's an open, distributed model in which the whole notion of "trust" is put back in the hands of users (where it should be). It doesn't treat trust as black-and-white decision, but as a matter of degree, which better matches the human concept of trust. And it's a system that constantly re-evaluates the trustworthiness of every user and site rather than having to rely on CA's to certify/revoke given entities in a timely manner.

Re:Certificates are a scam

[Anonymous Coward]

Imagine that, it's easy to gain the trust of computers that you have direct control over. How about end-users that do not belong to your organization? You know, customers and such.

Re:Certificates are a scam

[c0d3h4x0r]

I had a follow-up idea.

You can remove the need for users to "metavote" on each other, and make calculation of user trustworthiness an automatic part of the system.

Assume a ten-point trustworthiness scale for web sites. Suppose a given web site has a current trustworthiness score of 7, and suppose I think the site is really untrustworthy and I rank it as 2.

Just the act of my voting "2" implies that I don't really trust people who gave the site radically different scores. I might mostly trust someone who gave the site a "3", but I really don't trust someone who gave the site a "10". So the system automatically casts a vote, on my behalf, for "9" (10-(3-2)) for the person who voted the site as "3", and automatically casts a vote for "3" (10-(9-2)) for the person who voted the site as "10". Now those user's trustworthiness scores are accurately affected.

Re:Certificates are a scam

[feenberg]

It hardly seems likely that CAs do any significant checking. Years ago Verisign sold us a cert based on a faxed letter, and just last week we bought a cert based on a telephone call to a number I supplied (not our listed number), on a Sunday in about 5 minutes. I paid with a personal VISA card, so that couldn't be the basis of any checking, and as for access to an email address, there was no indication on the site of any restrictions as to the email address. In any case, email authorization is an alternative to telephone authorization. The cert (from RapidSSL.com) seems to work fine with MSIE and other browsers. I can't say I know what security procedures are in place, but if they can implement them with so little inconvenience to customers as this, they can't be very strict.

Re:Certificates are a scam

[owlstead]

Can somebody *please* mod this down? First of all, a certificate is not a number. You can write your own certificates, but they won't be trusted by any browsers. The end user does indeed not know about trusted third parties (TTP's) as they are called, but as long as the browsers do, they don't need to. "UltraSecure" and "SafeClick" are not part of the browsers trusted certificate store, and the browsers will rase hell if you try and authenticate with root certificates with that name. And, as another user noted, having to pay for a certificate does make a difference. You need to be known by a bank, and you cannot create any number of certificates.

You don't know shit about certificates and you are spreading fud, mister AC.

Re:Certificates are a scam

[Miniluv]

What are you saying is linked to an IP address? The certificate sure isn't, it's linked to an FQDN in most cases, simply a domain in some. You may be confused with the fact that you cannot used name-based virtual hosts when using SSL, which is due to the sequence of events in establishing a TLS secured HTTP "session".

CACert TTP program

[Anonymous Coward]

The site talks about doing paperwork for TTP. Yet I can find no link to the TTP paperwork.

Can someone post a link here, or edit the wiki so finding the TTP paperwork is simpler?

Re:CACert TTP program

[crush]

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

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.

Re:We already have

[Anonymous Coward]

Do you not know what TLS is?

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.

Re:Main use would be code-signing

[crush]

CAcert also offers free, personal certificates based exclusively on WoT checking, and Class3 certificates for code-signing, it's similar to Thawte's model except for the free Class3 certificates.

The big hurdle seems to be that the Mozilla Foundation won't include the CAcert root certificate in the browser because CAcert doesn't pay them (unlike all the other root authorities).

Re:Main use would be code-signing

[Anonymous Coward]

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.

Where can you get these? This would be plenty adequate for my purposes. Can you post a few links?

Re:Main use would be code-signing

[YGingras]

GPG is used daily to sign releases and histories and patches on several revision control systems. I guess you mean signing for runtime loading like in ACS. When patches signing with GPG was implemented in GNU Arch, I remember someone said on the mailing list: "I'd rather have a key signed by Manoj than one signed by the pope". I think that this represent well how decentralized trust (GPG, PGP) compares with centralized trust (SSL). Centralized trust works if you trust the CA. But, being the CA gives you enough power to get corrupted. So we end up with Verisign on top of all the CAs and we don't really trust anything. I really like how signing is implemented in GIT.

Re:Main use would be code-signing

[Yggdrasil42]

The big hurdle seems to be that the Mozilla Foundation won't include the CAcert root certificate in the browser because CAcert doesn't pay them (unlike all the other root authorities).

I don't know where you get that idea? Inclusion in Mozilla browsers is actually free. They have strict guidelines that CAcert needs to conform to, and both Mozilla and CAcert are working towards that, but it takes time. Microsoft is another story and requires CA's to pass an expensve audit, with a yearly upkeep. It's a lot of money for a free CA. See http://wiki.cacert.org/wiki/InclusionStatus#head-8 c0235dd1ebf0ce0aa1bd7c050378aed97dc335c for more info

Re:Main use would be code-signing

[Kalriath]

https://www.godaddy.com/gdshop/ssl/ssl.asp Godaddy does 'em for $20 per year. They're even a real root CA, not chained from Verisign, Thawte, Equifax or Comodo. Woah, they even have EV-SSL for half of Verisign's extortionist price.

Re:Main use would be code-signing

[crush]

I'm wrong. Thanks for the correction.

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.

Re:Why OpenSource?

[Anonymous Coward]

Quite simple: get audited to WebTrust or ETSI. Open source street cred doesn't mean bupkiss if you can't pass these audits. That's where money and expertise are needed. The browsers do not charge for root distribution - but with more than 70 CAs distributed in the browsers, they need an impartial standard to judge a CA's quality. Apparently CAcert doesn't cut that mustard.

Thank you.

[Anonymous Coward]

Talk about hitting the nail on the head; I couldn't have said it any better myself.

Personally, I think the submitter just wants free certs. Granted the prices the big boys charge are simply outrageous, but I don't like the idea of any random, anonymous asshat being able to get a free cert signed by a root CA trusted by the default operating system / browser installation. On the other hand, nobody pays any attention to certs anyway so maybe it wouldn't be any worse than it is now.

Awesome!

[222]

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

Re:Awesome!

[222]

Whoever modded that troll should investigate where Ubuntu founder Mark Shuttleworth gathered his wealth...

Jeez, anyone with a sense of humor around here?

Re:Awesome!

[kriebz]

I got the joke. /me laughs out loud
I just got done explaining Thawte to my friend when I read your post.

PGP?

[Anonymous Coward]

"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

Shuttleworth

[matt me]

Thawte was developed by Mark Shuttleworth. He sold it for $560 million in 1999. He's now responsible for Ubuntu.

am I missing something here?

[rucs_hack]

I thought the whole idea of trust certificate type things was because the closed source ethos means there's no way to know what's in the program you're installing, so it has to be certified as trustworthy?

I didn't think open source needed that kind of thing.

When it comes to installing things via browser I prefer firefox's 'authorise this domain' thing, which is independent of certificates.

perhaps the reason there's no open source equivalent of these certificates is that its never come up as a problem.

I may be missing the point, as I said, but I am a mere academic hacker type, all this buzzword filled security stuff tends to pass me by. The only security I have in my software is 'if you run this as root you're a dickhead', only not that rude.

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)

Re:am I missing something here?

[Anonymous Coward]

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

(-1 offtopic) Yeah I know but it's worth saying anyway...

This idea that the old are unknowledgable is very misleading. The Slashdot generation doesn't realise how fast time has moved on since 1985. The mothers, fathers, grandmothers and grandfathers... They are us. Or very soon will be. The problem is the younger generation who I am beginning to notice are some of the thickest people imaginable. The majority of those up to their mid 20s are now the ones we should be concerned about. They have terrible communication abilities, piss poor maths skills, no faculty of critical reasoning, an apathetic and entitled attitude.

Your grandmother could academically outperform any of the ignorant little bastards our public school system is churning out. That's the frightening thing, because when the smart people of the older generation are dead these uneducated idiots will be around screwing things up for the next 60 years.

Re:am I missing something here?

[DamnStupidElf]

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.

Who is mozilla.org? Can you tell me exactly who they are or are supposed to be? What about mozilla.com, mozilla.net, mozilla.tw, mozilla.cx, etc. What about mozilla-browser.com or mozilla-firefox.org? Does any of those names actually mean anything in and of themselves? No, which is the entire problem with DNS based certificates. People trust entities by vague association by name and function, but with nowhere near the certainty that any public key infrastructure provides. What's really needed is a web of trust that lets users see what other people think a public key identity is actually used for, and what comments they have about it. It should look more like myspace than a lock in some website's window: It should be obvious that a whole lot of people think a given public key belongs to the well known Mozilla Foundation.

Re:am I missing something here?

[logixoul]

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

Re:am I missing something here?

[Kalriath]

https://addons.mozilla.org/

"The web site addons.mozilla.org supports authentication for the page you are viewing. The identity of this web site has been verified by XRamp Security Services Inc, a certificate authority you trust for this purpose"

Re:am I missing something here?

[Solra Bizna]

Yay.

-:sigma.SB

Re:am I missing something here?

[Anonymous Coward]

So you're sure we're on a path to Idocracy?

Commerical Interest and market leaders

[youthoftoday]

Whatever people say about the market share about !IE, MS is still a signficant player in the browser market and will be for at least $\infty$.

I'm sure that the a hypothetical CA would more than happy to 'do a deal' with a hypothetical market leader on browsers to ensure the competition were locked out of mainstream acceptance.

You don't get your cert onto IE, you don't get your cert onto the net. Especially as so many high security organisations (like banks) stipulate (or used to until recently) that IE had to be used.

How long until this issue raises its head seriously and MS gets dragged through the courts over it?

Very Large Prime Numbers

[mosel-saar-ruwer]

Two points.

1) To be a cert authority, don't you need at least a medium-sized farm of supercomputers to mine very large prime numbers [<=, say, 2^4096] from the greater ether of non-primes? And ain't that gonna require some pretty serious investment $$$'s?

2) A little off-topic, but what happens in RSA if you cheat, and use non-primes as your keys? [Often the math will still work, but sometimes it won't - and what goes wrong if it doesn't?]

Re:Very Large Prime Numbers

[TheRaven64]

To be a cert authority, don't you need at least a medium-sized farm of supercomputers to mine very large prime numbers [

A CA doesn't need to generate a lot of primes, it needs to generate two. The product of these is then the public key. A CA only really needs a single certificate (a certificate is a public key and some data about the owner, signed by the private key). This is then used to sign the ones their customers provide. OpenSSL includes everything you need in order to be a CA. You generate your public and private key pair with it, your customers can generate theirs and the certificate signing requests, and you can sign their certificates with it.

Having the CA generate your certificates would be a very bad idea. At no point should your CA (or anyone else) have access to your private key. Roughly speaking, a CA works by having providing customers with some data that can be attached to the certificate (and including a hash of the certificate) that is encrypted using the CA's private key. Someone downloading the certificate who has the CA's certificate can use the public key from that to decrypt the signature from the certificate, and verify that the CA believes that the certificate is valid.

A little off-topic, but what happens in RSA if you cheat, and use non-primes as your keys?

Then you get nonsense out. RSA is based on modulo arithmetic and only works correctly if you have no common factors. For certain messages, you could create non-prime keys that would work, but it would be a lot more effort to find them. The only keys that work for all messages are primes.

Re:Very Large Prime Numbers

[fwr]

1) To be a cert authority, don't you need at least a medium-sized farm of supercomputers to mine very large prime numbers [&#140

No. If you're unaware of how CA's work, they just sign certificates. That's their primary purpose. The end-user or RA may generate the certificate that the CA signs. Or you may have the CA generate the certificate for the user. Or the CA can download a small applet and have the end-user do the work as far as generating the keys. However, the preferred method is to have the end-user generate the keys in the certificate. There is no reason why the CA needs to know the private key for the user's certificate (which they would necessarily need to know if they generated all keys for all certificates). You can run a CA on open source software now. Ever heard of OpenSSL? Just create a self-signed certificate and wala, you're a CA. Whether anyone recognizes you as a CA is another question, but you have all of the certificate signing capabilities that any other CA has.

Re:Very Large Prime Numbers

[Anonymous Coward]

Hey check it out! I'm too stupid to close a blockquote tag, too!

Re:Very Large Prime Numbers

[wkk2]

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.

I use a Cryptoflex card for ssh. A public key can be safely placed on other computers and I have access whenever the smart card is inserted in my local USB reader. An OS with spyware can still listen but it can't get into remote computers when the card is in my pocket.

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:Very Large Prime Numbers

[Vintermann]

Heard of Miller-Rabin? very large prime numbers are cheap.

Sorry, didn't preview

[Proud like a god]

"...an Open Source CA system to exist,..."

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:Encryption and authentication are conflated

[TheRaven64]

You can't unlink them, because they are so deeply connected. TLS without identity gives you no security. All you have is an encrypted connection to somewhere, but no guarantee that it is the person (or machine) you though you had an encrypted connection to. Someone one router upstream from you could be proxying all of you 'encrypted' connections so you get an encrypted connection to them and then an unencrypted connection beyond that. Without a signed or pre-shared certificate, you would have absolutely no way of knowing if this is happening.

My feeling is that the current system is too binary. Trust is not a binary thing; you don't either trust someone or not trust them. You might trust someone with £5 to get you something from the shop but not trust them with your bank card and PIN, for example. You need to be able to build your own trust network, based on personal verification. I proposed a couple of years ago that IM should be linked to identity functionality. Most people have met several of the people on their IM rosters in person, and so can be sure of their identities. They can then use the transitive property (weakening the trust at every jump) to create the trust chain in an ad-hoc way. If I buy something from Amazon, for example, and they don't defraud me, then I would indicate that I trust them a bit. Everyone who has me in their roster would inherit a small amount of trust-for-Amazon, and would be able to use me to verify their certificates. If I had time (and/or funding), I would develop this idea further, but currently I have too many other projects.

encryption only

[dkh]

The crux of the problem is that the CA's have a different view of what the certs are for then the end users. They also have a vested interest in viewing it the way they do.

The person sitting at the browser wants to know that the communications are secure and they don't want to see any scary messages. Most of them do not have any idea that the the certs are also supposed to confirm identity.

There should be room to allow for encryption only type certs.

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.

Absolutely Yes

[Apreche]

In order to do any sort of secure transaction on the web, you need SSL. If people don't see the little lock icon, they will be very unlikely to trust your website. To get that icon you need a signed SSL certificate. Sure, you can sign your own. However, if your cert isn't in the browser, then users will get a warning popup that your site might not be safe. That's worse than not having the lock in the first place.

Verisign, Comodo, and others have a big scam going on. Whoever wants to conduct secure business on the web needs to pay one of them a toll to get their certificates signed. There's no reason that this should cost money. Signing a certificate is such a trivial activity. It's more effort to write this post on Slashdot than it is to sign a cert.

We either need a new security mechanism for secure transactions on the web or we need a free and secure way to get certs signed. Without this, we will always have a few companies acting as gatekeepers deciding who is allowed to conduct secure commerce on the web. That is not cool.

Re:Absolutely Yes

[Have Blue]

If self-signed certs were accepted at face value by browsers the entire thing would fall apart because it's just as trivial to sign your cert with "Amazon.com" as it is with your real name. And it takes money to determine that the guy who typed "Amazon.com" into the Buy Cert form and hit Submit actually works for Amazon.com, because that's far more complex than just typing his name into Google and looking for bad feedback. You have to do work in (gasp) real life.

It's absolutely a good thing that getting a secure site accepted by browser is an expensive pain in the ass, because that is a barrier to entry for real scammers. Just imagine how bad phishing would be if they could get the little padlock on the browser to light up.

Re:Absolutely Yes

[Anonymous Coward]

Whoever wants to conduct secure business on the web needs to pay one of them a toll to get their certificates signed. There's no reason that this should cost money. Signing a certificate is such a trivial activity. It's more effort to write this post on Slashdot than it is to sign a cert.

It's not the signing that requires effort & costs money, it's the verification & validation before the signing that requires effort & costs money.

Of course, many CAs don't do much verification & validation, but that is a different problem.

On the other hand, if your online business can't afford $20 to get an SSL certificate from godaddy, then I don't have much faith in the viability of your business. In most jurisdictions, forming a corporation and registering a business costs much more than $20.

Re:Absolutely Yes

[neoform]

>That is not cool.

Right on maan, that does NOT ROCK..!!

Security.

[k1e0x]

Thats really the reason why people dont use encrypted e-mail.. Nobody can make it free and simple without any hassle.

We already have a OpenSource friendly CA StartCom. http://www.startcom.org/ It would be nice is Mozilla included them and if Thunderbird automaticaly generate "Idenity unverified" certs for its e-mail users.

I dont know, maybe its not possible.. still it would be nice to shut down Verisign.

Re:Security.

[StartCom]

Mozilla and many other have included the StartCom CA. See the full list here: http://cert.startcom.org/?app=140

Re:Security.

[k1e0x]

Oh, Thats great. Yeah, StartCom should startup a free e-mail cert program that we can get a app (like seahorse) included for a "it just works" e-mail cert creation and lookup.

On another note I noticed that StartCom was pulled from Wikipedia.. whats up with that?

Re:Security.

[StartCom]

Wikipedia removed anything related about StartCom from it. They declared war on StartCom for whatever reasons, most likely there is a connection between CentOS/Cacert (and the wikipedia admins) and StartCom. StartCom produces amongst others a Linux distribution, but also runs the Free SSL Certification Authority.

What do you mean by free e-mail cert program? StartCom provides free S/MIME certificates and is also progressing to run a Web of Trust system.

Re:Security.

[k1e0x]

What I mean is.. it would be great to have a system like..

Your Mother sits down at her computer to write her sister a letter. suddenly she thinks.. "Hmm, I only want my sister to read this.. its personal." She selects "secure message" from the toolbar in Thunderbird (or Evolution) This starts a "create new encryption key wizard" That she easily completes with a few short tasks then sends the message encrypted to her Sister.

Now of coarse, that does not work.. she would need her Sisters key but.. but in concept that would be nice and easy.

Re:Security.

[StartCom]

Since the free Class 1 certificates at Startcom are email validated only, it could be in theory possible to write an extension (for Thunderbird) or plugin (for the rest), which would send a prepared certificate request to the CA and upon receiving of the verification key for this client certificate also install it. Guess this could be made very user friendly indeed, without the need to go through the web site wizard as currently. That could be a good idea and might make S/MIME certs much more popular ;-)

Re:Security.

[Trejkaz]

It could work, just need to fetch the key from a public keyserver as everyone has been doing for some time now.

In practice though not many mail clients automate fetching the key. That's partially for security -- you don't want a key you haven't checked getting used automatically. But they could always prompt the user. And using various other tricks it could be made easier to exchange keys directly (e.g. build a new feature into mobile phones. :-))

Re:Security.

[k1e0x]

I like that.. someone should get on this / spread this idea around.

What Joe Q Publick is really asking for is...

[RealBothersome]

Along with secure shopping, we need a way to send email encrypted. When I click on the enable encryption under tools on my email program, it should tell me about generating a public key set. Then when I want to send an email to a friend, it would tell me about needing my friend's public key. The program should send off an email to that friend asking for his public key with my public key in-tow (or get it from a key server). Then the friend can click on a link that was in the email that I sent, and his key pair would be generated or simply send his public key to me if already generated. I get his public key and am notified that I may now send him encrypted messages. Simple as can be, Why has it not been implemented yet Seamonkey or Thunderbird?

Re:What Joe Q Publick is really asking for is...

[Trejkaz]

Using a key server is probably the easiest approach, seeing as we already have all the infrastructure for it (i.e. the key servers already exist, and are widely used.)

Re:di43k

[rs79]

"you have a play itself backwards, very sick and its it has to be fun it a break, if In addition, be a lot slower may weel remain Abysmal sales and a conscious stand survey which backward and said tangle of fatal obsessed - give continues in a its corpse turned subscribers. Please IS DYING LIKE THE Core team. They sales and so on, Munches the most Creek, abysmal users. This is get how people can up today! If you least I won't log on Then the [nero-online.org]. Gawker At most wasn't on Steve's"

My decoder ring says this tranlates to "Meet Grovneck at the embassy at midnight".

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

Instruct the user how to accept your Certificate

[tburt11]

More often than not, when I go to install a new software into my Windows computer, I am presented with a warning that the software has not passed Windows Authentication. Usually, there is either printed documentation, or a window below the warning, telling me to ignore the warning, and Click OK.

I have done this enough times, that I now click through the warning without hesitation.

A visitor to your secure website could be likewise instructed to ignore the warning, and told to explicitly "add this Certificate" which will permanently dispose of the warning.

Seeing this warning once or twice, the public will become accustomed to adding Certificates, and the Monopoly of the CA's will be damaged or broken.

The answer, therefore, is to make liberal use of Independent Certificates, or use as your CA, a commonly used Open Certificate. For example FOSSCA.

The major Authorities will try to smear as untrustworthy the FOSSCA but eventually, people will click through it, just like they do with the Microsoft warning.

Responsibilities of a Certificate Authority

[StartCom]

Running a certification authority has many, many responsibilities. Since open source and community related structures are handled most of the times by volunteers, such a CA is almost not possible. There are things at a CA which can't wait for some volunteer having the mood to do it. CA policies don't allow much playroom, but requires strict adherence to it.

StartSSL of StartCom is the closest it can get what pricing and openness concerns.

Real lack of fundamental understanding here

[CPE1704TKS]

The whole point of Certificate Authorities isn't just to distribute certificates... it's to make sure that the certificates are valid and that they are giving them to the right people. Being able to make whatever certificates I want makes the entire thing meaningless. If there is an open source CA, I could create a certificate that says I'm Linus Torvalds or Bill Gates... who would make sure that I'm really who I say I am? If you can't guarantee that the cert is correct, then it makes the CA useless.

The only way you can make it meaningful is by having some type of investigation. Granted, most low-level certs are pretty much rubber-stamped however, there is the concept of higher-level certs that require more and more verification. For example, code-signing certs probably require a higher level of verification.

This costs money and there has to be some sort of financial interest to generate this.

The issue isn't the source code for CAs, Openssl has the code to generate certs, which makes it a valid CA, it's about making sure the certs are valid.

Open Source?

[desideria]

How can a certificate authority be "Open source?"

Maybe what the submitter meant to say is free (as in beer)?

Shooting at a moving target

[Excelcia]

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 wish I could apply moderator points to articles so I could vote that part of it flamebait.

On day one, there were no requirements to get a root certificate in Mozilla. Mozilla essentially played a "me too" game in the beginning, putting in root certificates fairly willy nilly. It was only when CACert appeared on the scene that Mozilla magically decided on a set of standards. Not right away, of course. No, first they dragged their feet, then admitted it was an issue that needed dealing with, then created a policy and promised CACert would be added. That was three years ago.

I suggest the buzilla report on this issue as interesting reading. Speficially Frank Hecker's post is illuminating.

No one could have worked harder with the Mozilla foundation than CACert.

Re:Shooting at a moving target

[StartCom]

...and promised CACert would be added. That was three years ago...

This is, because they didn't comply to the Mozilla policy. There was no such promise, but essentially made it in theory possible for them to be able to comply to the said policy. However one of the things Mozilla didn't recognized back then is, that there are real problems in an open, community only structure.

Free is not a criteria of certification authorities! This is what many supporters of Cacert don't understand...

Identity Verification

[madsheep]

I think the OP is worded a little strange and but I think I understand what you are getting at. The problem here is, as others have pointed out, you would essential have a free service and you get what you pay for. Who is going to do all the identity vetting and verifications of those requesting certificates? Are you going to have a full time staff that is verifying who individuals are and that they're authorized to be making such requests? What are the odds tons of *.microsoft.com and *.whatever.gov certs get issued? My guess is this would either be an unusable service (extremely slow in turn around) or it would be absolutely useless.

Why would it be useless you ask? (two main reasons)

Reason 1: With this sort of poor service I highly doubt anyone would want to trust this root certificate in their web browser or anywhere else for that matter so it would really be no different than a self-signed certificate.

Reason 2: If this service was trusted, it would be a major security issue. I think the number of people getting certificates that should not have them would be 100x what it is now.

Yes as you can see by my last statement in 'Reason 2', I am aware that there are times VeriSign or others have fowled up and accidentally issued certificates to those they should not have. However, I guarantee you this would happen much more often with a service like this. Also, the number of times this has occurred is amazing low -- due to a good process. With these other CAs you get what you pay for.

Oh yea -- last comment which I know you guys will love. Microsoft will never put this into IE! What does that mean? It is borderline useless. IE still has the majority of the market share. You can argue with it all you want, but it is true. You can import any CA's root cert to your browser of course. However, we're looking at things here on a grand scale. Not just what a group of 20 nerds want to do.

Mozilla

[StartCom]

Should this community be related to the Mozilla Foundation and comply, since day one, with the requirements to get a root certificate in Firefox?

Mozilla has an open policy. The problem is not Mozilla, but as in your suggestion Cacert, which in four years time failed to comply to the policy of Mozilla.

However there are essential problems running a CA by volunteers - which one of the reasons why there isn't any such volunteer CA supported by major software vendors.

How About SimpleCA

[Anonymous Coward]

I have used SimpleCA and it seems to do the job. I am thinking why not use simpleCA for a closed community. Of course, Internet is a different issue.

Solution in search of a problem

[Spazmania]

I think the whole certificate authority scam is a solution in search of a problem. Yes, there are useful man-in-the-middle attacks where a public key hasn't been independently validated. I won't claim otherwise. I will claim that for nearly every application there are so many avenues of attack with a higher probability of success that worrying about key validation is a little like digging a nuke bunker while terrorists buy plane tickets.

For one thing, you don't have the wherewithal to dig a nuke bunker than allows you to survive more than the most cursory nuclear exchange and you probably won't be near the bunker if it happens anyway. For another, the focus of the attacks which aren't just in your imagination is elsewhere.

Unless you demand perfect encryption in everything, you won't be ready if the attack ever does come. And you won't demand it because you're not prestigious enough for your field of contacts won't put up with your folly. Besides, its the buffer overflows and related software bugs that are going to get you. Until that starts to draw to a close, worrying about key validation is an exercise in futility.

Re:Solution in search of a problem

[owlstead]

As long as you keep sending responses like that, I would not bother about encryption either. I'm trying to decode the response for a few minutes now, but I am drawing a blank.

Re:Solution in search of a problem

[Spazmania]

What I said, in so many words, was that a certificate authority (open source or otherwise) generally locks the closed front door while the back door and all the windows are wide open. If that metaphor is too obtuse, I'll state it more directly: certificate authorities are presently a waste of effort.

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:Zimmerman has it wrong

[QuietLagoon]

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.

What I am really interested in is whether or not the person I am talking with is real and accountable. I do not want to talk with some ficticious identity multiple times, as Zimmerman would proffer as something beneficial.

How do you define "good"?!?

[vanyel]

Thawte's interface is good

Clearly the author of that quote hasn't actually tried to use Thawte's site much. Cumbersome and arcane are better descriptions...

Someone didn't do their homework...

[Excelcia]

Someone didn't do their homework. Sorry, but you failed to read the assignment so you get an 'F' in popular history.

This is, because they didn't comply to the Mozilla policy. There was no policy when CACert began asking. Read the bugzilla report and you will see how they only decided they wanted a policy after CACert came knocking. I don't know about you, but when an organization accepts certificates from all comers and then when I come around they say "sorry, but we only accept certificates by those who meet a policy we haven't drafted yet", then I start to feel snubbed.

There was no such promise

Ok, since you don't like to visit links when they are handed to you on a platter, not even when the relevant message is directly linked, I'll quote the whole thing here:

My sincere apologies. I suspect that I may have been the bottleneck here -- I'm the person tasked with developing the mozilla.org policy on inclusion of root CA certs, and with approving noot root CAs for inclusion. Unfortunately between work, my wife's back surgery, and caring for a 17-month old child I have fallen badly behind on both getting the policy completed and approving any new CAs.

In any case, I have looked over the documentation provided for CAcert, and I approve of including their root CA cert in Mozilla. I'm not the person who does the actual work, but I'll send that person an email to tell them to go ahead and include the cert as soon as possible.

Again, I'm very sorry for the severe delays in getting this issue resolved.
[italics added] This was posted February 2nd, 2004. More than two years ago. That looks to me to be exactly what I described - a promise by someone at least claiming authority to do so to add CACert's root certificate to Mozilla.

Re:Someone didn't do their homework...

[StartCom]

Since Mozilla is an open organization where the community has a lot to say, some members raised valid points against such an inclusion. At the end of the discussion which followed, Mozilla did the right thing and developed its own CA policy. Any CA adhering to this policy can be potentially included into Mozilla software as StartCom has done it.

Re:Someone didn't do their homework...

[Excelcia]

So, basically what you seem to be admitting to is exactly what I pointed out in my original post - that CACert was given a moving target to hit. They request inclusion at a time when there are no standards and get told no because there are no standards. Excuse me? But if they can just wait... we'll make a standard. Meanwhile, other certificate authorities are being added, but ok, they wait. For a year. They wait for standards to get set and then meet those standards, but that's not good enough and the standards change. So the merry-go-round goes around again. I stopped following it in detail a couple years ago, because I found I would just get angry at the 'wtf' factor of it all.

Which brings me to another post of yours, suggesting that "[t]he problem is not Mozilla, but as in your suggestion Cacert, which in four years time failed to comply to the policy of Mozilla". Now that's a little disingenuous don't you think? More of that 'wtf' factor - sort of a capital 'WTF' really.

Re:Someone didn't do their homework...

[StartCom]

Well, the description of your history is correct in that, that when Cacert wanted inclusion at Mozilla, all alarm bells came on...So far so good.

But the Mozilla CA policy exists in some form since beginning of 2005 at the web site of Frank Hecker (President of the Mozilla Foundation). That was about when StartCom started its own authority. Since then many CAs were included and processed at Mozilla (See history), based on that policy, the very same policy which was eventually approved my Mozilla.

Therefore what I meant is, that already for over two years, Cacert could have been included - the very same way StartCom was. More than that, the Mozilla policy was created and defined in a way, which made it possible for Cacert and StartCom to comply.

However, I think that there are some real problems with community projects in order to have them comply even to the most basic requirements of CAs. This is one of the reasons, why I personally don't believe in the current structure of Cacert to be ever successful - even if it's a nice idea.

What's

[KKlaus]

the point of having the card in the first place then? Maybe I'm mistaking your suggestion for something else, but what role exactly is the actual card playing here?

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.

Re:What's

[FLEB]

Paper? I know both by rote.

Re:What's

[Anonymous Coward]

Paper? I know both by rote. Yeah, I knew my new number within six hours of getting my latest card.

I am Amazon's bitch.

Open source CA StartCom supported by Firefox

[miller60]

CA Cert gets much of the attention in the discussion of open source CAs, but StartCom has made more progress in gaining browser support (and hence market acceptance). StartCom certs are supported by Firefox 2.0. CACert has been working on inclusion in Firefox for several years, and appears to be getting close. Mozilla has stepped up its staff effort to review certificate authorities for inclusion in Firefox/Mozilla, including CACert.

Startcom

[Anonymous Coward]

Go to http://cert.startcom.org/

I suppose . . .

[DaMattster]

that many slashdotters here make a good point about it really not being necessary to have an open source CA. CACert does the job really well and I use it for internal communication security. If you really need your own CA, it is not terribly difficult to put together a very rudimentary one. In fact OpenSSL provides just that, a very simplistic, basic CA that is not terribly user friendly at all. See the man pages for openssl ca and openssl.cnf.

Open Source Authority?

[geekyMD]

Open Source Authority = biggest oxymoron of the decade! :)

A true open source CA with secure practices is $$$

[mlts]

A true "open source" CA is almost an oxymoron. You want a CA that you trust enough that you put its cert in your browser and let introduce you to people to do the following:

1: Screen companies/people. If an applicant out of nowhere says they want a cert saying they are bigcompany.com, they better have proof of this that can stand up in a jury trial, or your CA will immediately lose trust, get hit by civil/criminal charges, and be an avenue for phishers.

2: Store the CA signing certificates in a hardened FIPS 140-2 level 3 or so HSM. The CA's private key, because its so critical to everyone in the infrastructure will end up being a big fat juicy target for hackers and physical thieves around the globe. You can't just stick it in your Windows keystorage and call it secure, you have to have hardware which is physically tamper resistant that meets up to very strict standards. Smart cards do have protection, but attackers will have enough money to throw to be able to find a way to physically decode each cell's contents on the card. Also, the private key will be used a lot, so the HSM will have to be very fast for all the transactions.

3: Browser vendors, to have a root cert, will demand auditing by an independent third party annually or semi-annually. This is expensive, in the five digit range.

Since all the above are expensive, this is why CAs have to charge, as the capital for the hardware and internal audit processes will easily top six figures, possibly seven if you factor in bandwidth, hosting, physical secure location (building with access cards).

How to do low cost certificate verification

[Animats]

There's no big problem running a certificate authority at a moderate cost per transaction. It could probably be done effectively for about $10-$20 per certificate.

If you want to buy a certificate for an organization, identity has to be verified. The way to do this is 1) look up the organization in corporation or d/b/a name records, as appropriate, and 2) send a letter or FedEx envelope (extra charge) to the address for service of process listed therein. You'd order a certificate on line, but it's not enabled until the letter is received and the code in the letter is entered. Disallow P.O. box and PMB addresses. This provides reasonably good address checking.

Generating the mailing pieces can be outsourced to a direct mail company. There's a whole industry out there that will print stuff, put postage on it, and get it into the postal system at very low cost. (Typical cost for this is about $0.47 per envelope sent.)

For an individual, require purchase with a credit card, and send the letter to the billing address of the credit card, which can be verified during credit card verification.

This yields certificates that provide solid address information, but without manual processing.

It's not free, but it's definitely possible to get the cost down.

I'd like to see this done for domain registration. The domain doesn't go live until the WHOIS information has been verified in this way. That would solve the junk WHOIS info problem.

Re:How to do low cost certificate verification

[vidarh]

For an individual, require purchase with a credit card, and send the letter to the billing address of the credit card, which can be verified during credit card verification.

That's true for only a handful or so countries in the world, and even for most of those the address verification services are woefully incomplete (that is, you have to expect them to return no result or wrong result for a fairly large percentage of users).

Re:How to do low cost certificate verification

[charter77]

"There's no big problem running a certificate authority at a moderate cost per transaction. It could probably be done effectively for about $10-$20 per certificate." And funny enough there are tonnes of vendors selling at that $10-20 level for low validation certs.

Re:A true open source CA with secure practices is

[Anonymous Coward]

Similar arguments could apply to an open-source encyclopedia:

- There is a need to screen Articles/People who write articles
- Equipment needed to run an open-source encyclopedia costs big bucks

But wikipedia is a success.

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.

Again, a lousy slashdot post

[Anonymous Coward]

What the hell is an open-source CA???

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)

Uh...

[Remi0o]

Uh, yeah.

What TLS is

[DrYak]

Do you not know what TLS is?

TLS and SSLv3 are cryptographic protocols which provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. (Thanks, Wikipedia).

The interesting thing is that they can operate using certificate issued by a CA just like their predecessors (SSLv1 and SSLv2). And thus, you can just do HTTPS as before, only with a slightly more recent protocol.

OR, you can use OpenPGP keys (PGP, GPG, etc) instead. Thus bypassing the whole CA stuff, and using PGP model of trust (1. Same key = same person as last time, who ever it was - 2. Web of trust though signing of keys. You signed it ? It's a key you trust. Some of your friend signed it ? It's maybe a friend's friend. Etc.)
No need to check it against a CA key, instead you check if it is inside you keychain and if so, with which degree of trust, or if not, ask you if you want to accept a new key (that you have to verify by some means).

Thus, small users that aren't interested in paying for a CA issued key (for Thwate or Comodo) or don't want to go trough the whole hassle of verifiably certifying who they are (for anything more than an email with CACert), can just use an OpenPGP key pair, and maybe sign their key with a couple of other source, or do some other stuff, in order to make their user sure that no spoof has happened.

Mostly useless

[Chuck Chunder]

Verisign may well revoke it, but do any browsers pay attention to revocation lists?
Besides, if you were being fraudulent you'd have probably moved on by the time the chargeback goes through.

I think you would have a very difficult time using registration details to track down someone interested in fraud, they don't tell you that a business is trustworthy.
Certificates are only really meaningful when you already have some trust in the business in question, such as your bank or some other big name.

There already is a Free CA: You.

[Sloppy]

OpenPGP lets you have multiple certs for a given identity. This makes it practical for anyone and everyone to be a CA.

RBL?

[Anonymous Coward]

Maybe we should have some like RBL for CACert? As the blacklist builds up, the end users will benefit from it by knowing which CAcert is not trustworthy.

An identity theif's fantasy

[Anonymous Coward]

The fundamental goal of CAs is to build a web of trust.

At least I don't want free certificates to be available that are pre-trusted in a browser.

Before I conduct a transaction that requires trust, I need some level of assurance that the other end of that transaction is who they say they are.
You need some barriers for people to prove they are who they say they are - otherwise the bad guys will take advantage of it - and the situation would be akin to spoofing email addrs and SPAM - arguably with more on the line like your identity or credit card info.

No thanks.

  why does this need to be 'open source'?

salt river project?

[Joseph_Daniel_Zukige]

So I look up SRP on google and it looks like you're talking about the stanford remote password protocol.

So I look on the competitive analysis (or something) page and I read something about Arcot Systems offering a software based multifactor and it seems to be recommended as stronger than ssh.

Red flags.

Any cryptographic key is subject to the physical possession vulnerability _by_ _definition_. Trying to handle parts of it in software just drops the bar. There are two problems with the hardware token.

One is that, just like a lock is pickable, hardware tokens can be analyzed.

(One advantage of tumblers is that picking a lock requires a certain amount of expertise to perflorm without being obvious. Electronic keys can be analyzed, well, electronically.)

The other is that the token is subject to the man in the middle. (The collars on card readers at ATMs in the UK, are one example, MSWindows 'bots are another.)

If a bot has a an encrypted software token on it, it has the library to read it, the library can be used by the parasite as easily as by the host. Anybody recommending a protocol that is supposed to be better than ssh who doesn't recognize this can't be trusted.

Their characterization of SSH as a "pseudo-strong" method (ergo, inferior to srp) seems to be entirely based on SSH's ability to fall back. If falling back is a problem, /etc is your friend. Near as I can tell without taking more time than I want to, the only advantage they can claim for srp is the lack of fallback.

Re:salt river project?

[Anonymous Coward]

Um... You've been trolled. In fact, very badly.

human in the loop

[Joseph_Daniel_Zukige]

is actually the only solution.

People who (emotionally) need faceless on-line shopping should pay extra service charges and put up with some extra steps for the authentication.

Alternately-abled individuals should be able to get the extra fees waived.

The rest of us can jolly well take a walk to a local authentication center where someone who probably recognizes us our face can check the photo-id on the card, log into the appropriate merchant network, and put an ack signal on the purchase we've just made on-line. Could be a convenience store clerk or somebody at the [insert-name-of-superstore] service desk, or a postal clerk. (And keep Microsoft software and any general-purpose web browser, including Firefox, well away from the authentication network. In fact, the authentication network should not be visible from the web.)

What about the faceless on-line shopping?

Dedicated software browsers, one for each of your financial institutions. They are programmed with one-time pads and asymmetric authentication, so they just won't even connect with anyone but the financial institution they are programmed for. You go to your brick and mortar local office when you need a new one-time pad and when you first get the client app.

And they do not run on any general purpose PC or PDA. They run on a (probably somewhat standardized) $100 box that has a smallish, cheap LCD (type) screen and a smallish keyboard and plugs directly into your hub or router, not into your PC. (Yeah, I know the router is still a weak point, but we can work on that as well, once everyone realizes just how much of a mirage the junk Microsoft has been selling is.) You can browse the shop with your general purpose browser, and set up the cart, but you have to use the dedicated box to authorize the purchase.

But for the trusted network,

[Joseph_Daniel_Zukige]

everyone has to be their own first CA.

Mod anonymous parent up!

[Joseph_Daniel_Zukige]

In the real world, we have multiple roots of trust. It should be the same in the networked world.

Just because the guys who thought up X509 couldn't wrap their heads around a plex, doesn't mean that we should turn back to that single-rooted single hierarchy. (Actually, they did understand it, sort of. Just all the people who stopped after the first chapter in the book that are stuck in the hierarchical sewage plug.)

Good ideas, except for the general purpose browser

[Joseph_Daniel_Zukige]

Dedicated browsers are necessary. I little bar in the browser will eventually be faked, and there will be a lot of Joe Sixpacks who ignore it and finance the cracker while he's figuring out how to fake it.

A dedicated browser simply refuses to connect. You get the browser and the CD with the current one-time pads and the bank's asymmetric keys from the brick-and-mortar local office of the financial institution.

Other than that, yeah, the user should be in direct control of the trust structures he builds. Otherwise, he can't trust it. The best the automated stuff can do is help the user make the distinction between the several webs of trust and their meanings.

joudanzuki

dedicated browsers

[Joseph_Daniel_Zukige]

If your financial institution builds its own browser (or contracts it out) it can put whatever certificate in it wants. In fact, if the dedicated browser does nothing but authorize a shopping cart previously filled on an unsecured web page, the dedicated browser doesn't even need a certificate. All it needs is one-time pads and an asymmetric key to talk to the bank. The bank could then talk to the vendor and verify some stamp on the cart, with the amount.

Certificates in a dedicated browser could perhaps make it possible to help a financial institution and a vendor who don't know each other get along, I suppose.

Re:Zimmerman has it wrong

[Vintermann]

How do you establish reality and accountability in real life? By meeting someone many times (OK, one is probably enough for establishing reality), and entering into various relationships with them. Say I want to buy something off someone on the net. Do I care who they really are, if I know that my friends has done business with them before, and that they have a public, verifiable history of honest dealing?

I think what you really want is accountability. Who cares about reality if you have accountability? And you can establish accountability in a Zimmermann-style system --- indeed, most accountability systems are based on Zimmermann-like systems in the end.

So, do you pay some company money so you can trust

[Joseph_Daniel_Zukige]

them?

I know people who say they do and then behave like they do, for some limited definition of trust.

But the truth is, no, you don't. Not really.

There are multiple roots in every one of your multiple real-world webs of trust. None of the real roots got to be roots by either taking your money or giving money to you. Some of the near-roots may have, and that can be confusing.

Well, you may have a single, ultimate root of trust, but that would by definition be your God. And, by definition, it would be hard to pin down, and hard to prostitute to the service of financial transactions. Unless you just have a pathologically low level of self-confidence.

Trust is not really something that can be automated. We can make an automated database of trust information, but when we try to automate the handshakes of trust, we are operating counter to reason, and counter to our own best interests.

All for the little convenience of on-line transaction. (Or something similar.)

joudanzuki

You don't need the mail itself encrypted.

[Joseph_Daniel_Zukige]

Only the attachment containing the information you don't want made public needs to be encrypted.

It would be "nice" if the browser could automatically read the attachment, but think about it. If you get a pin number in the mail from your bank, do you open it up out by the mailbox, or do you take it inside and open it up at your desk? (Inside so you can control the amount of observation, at your desk so you don't lose the letter.)

Here in urban Japan, yes, there will almost always be someone who passes close enough by as you are looking at the letter that they could catch a surreptitious glance if you look at it outside. Some places, you really would even want to draw your drapes before you open the envelope.

Why not encrypt the whole thing? Specifically because you don't really want your MUA decrypting it, even if you think it's inconvenient that it doesn't.

joudanzuki

open methods, open source software interface

[Joseph_Daniel_Zukige]

and a user interface that allows (requires!) the user to control the trust structures built and accessed by the clients.

No closed-source company will do this. Not so much because the PHBs won't allow it, but because closed source will always end up hiding something that shouldn't be hidden. Open source teams will (eventually) get the interface right and get the internals matching the interface.

Identity? Thawte (Verisign) knows identity?

[Joseph_Daniel_Zukige]

I think you misunderstand identity. That's not surprising. Many people do.

Something you have, something you know, something you are.

Huh? That's really just three things you have. A fingerprint is something you have until that finger gets cut off (either by accident or by someone bent on stealing your luxury car that uses fingerprints to open it). Something you know is just a bit of knowledge you have stored in your brain. An intangible possession, but a possession, nonetheless.

It's a little clearer if we say it this way:

(1) A tangible easily alienable possession, some sort of physical key;
(2) an intangible but easily lost possession, some sort of password (OK, passphrase);
(3) a tangible and difficult-to-alienate possession, basically a part of the body.

And when you say it like that, you see how ridiculous it all is. Three keys. Redundancy. That's all it means, except that the CAs managed to use the idea for a while to sell their product for more than even they claimed it was.

The current PKA is all upside down. Thawte should be sumbitting their certificates to us for arbitration, not the other way around. And that's why it should be open source, so that we control it.

joudanzuki

Closed Source Authority?

[Joseph_Daniel_Zukige]

is any less of an oxymoron?

wikipedia

[Joseph_Daniel_Zukige]

the AC parent mentions wikipedia.

I'd mod him/her up, but I decided to comment instead of using mod points.

That won't work

[CarpetShark]

"Hi, I'm your local bank representative. Mr Jones has called from Burundi, claiming to be a prince in exile, and saying that you want to give him the entire contents of your bank account. I'm not convinced about the prince thing, but that's between you and him. So you want me to authorise this?"

"Oh, it's another card auth call? Sure, go ahead, I'm watching the game..."

Re:That won't work

[Workaphobia]

So make that a direct communication initiated by the consumer at the time of purchase. Make them type a few extra lines and go through a few extra clicks from their card company's website. It's hardly a show-stopper.

"Open source CA" not a practical idea

[Ernesto Alvarez]

It seems that the discussion poster is mixing a few things. Being a CA is a full time job, not just the role of a program. Signing certificates and such is the easy part, the hard part is verifying the identity of the people asking for the certificates. Open source or close source is really an insignificant part, considering all CAs use open protocols.

If you wanted to get certificates for open source programs, it is very possible that the process would not be free (as in beer), or the process would not be trustworthy (because money is needed to make the investigation, possibly a global one). That does not mean that you should pay USD1000 for a thawte cert (that's armed robbery). But it means that an "Open source CA" is out of the question, unless someone with resources (EFF, FSF) steps in and does it.

The open source model is more adapted to a chain of trust organization. If I know someone I would certainly certify his identity, but if I did for any stranger, I would probably do a crappy job. Same applies with everyone else in the open source world.

Re:di43k

[Anonymous Coward]

Odd. My ring says "carne debajo del caballero medio embarazado"

Re: Its called "Verified by VISA"

[hicksw]

VbyV is not quite right. In my experience VbyV and I have a single shared secret which must be completely uttered as verification. One phish and you are lost.

HSBC has a much more robust method for using a shared secret. They ask for three digits of our shared secret number, as in "enter the second, fourth, and last digits of your pass number". They change the digit selection every few minutes, so any man-in-the-middle or key-logging phish is almost immediately useless. A minimum length secret of 7 digits allows 35 different challenges. This is sufficient for even a very simple backend process to detect attempted misuse.

My experience is limited to the UK. HSBC is not the most joined-up outfit I ever dealt with, so YMMV.
--
Never build a computer more wicked than yourself.

Running a CA properly is expensive

[ivan256]

I looked very seriously into doing this back in the 1999/2000 time frame. First I looked into doing it as an open, free system run by a group of ACM and LUG chapters. We had large scale commitments for donated hardware and hosting, but we ran into the problem you describe. The fees necessary to be included in popular browsers are too high. So then we planned on charging a minimal amount for the certificates in order to cover those costs...

It turns out that those fees you list are nothing compared to the costs of running a CA correctly. Even charging the same as what the "big guys" charge for certificates, you can't make enough money to properly validate the identity of a certificate applicant. Verisign and the like can charge as little as they do and still post the huge profits that they do because they don't do the work required to prevent the acquisition of fraudulent certificates. There is no way to undercut them on price if you want to provide a quality service. If you figure out a way, they'll buy you out to protect their revenue.

For the system to change, there needs to be a way to have the established vendor's authority revoked if they issue more than a set number of bad certs over a specified period of time. They shouldn't have a license to print money. They should have to actually provide the service they claim to provide.

SUE's should not be a design criterion.

[Kadin2048]

"Oh, it's another card auth call? Sure, go ahead, I'm watching the game..."

No system protects against absolute stupidity, and if you try, you end up with broken systems that punish reasonably intelligent users with multitudinous dialog boxes and warnings that just waste their time.

Remember: a fool and his money are soon parted; no technology developed now or ever is going to change that.

Re:SUE's should not be a design criterion.

[CarpetShark]

No system protects against absolute stupidity, and if you try, you end up with broken systems that punish reasonably intelligent users with multitudinous dialog boxes and warnings that just waste their time.

There's some truth to that, but when, for instance, there is a workflow that is required to ensure correctness, it's generally a very good idea to build that workflow into the system. For instance, if an editor should see an article before it goes to press, the article shouldn't be publishable without an editor's approval. One could apply the same logic to credit card transactions, and many other issues that naïve computer users often don't understand, or simply don't understand the need to take seriously.

No need to make your money accessible ...

[hadaso]

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

I think the only thing that's really needed is some kind of mechanism that ensures the merchant only gets info that's good for the particular transaction. so it should be a mechanism that replaces the credit card that receives info that includes things like amount, merchant code, time+date, unique transaction id created by the merchant (can be sequential number, random, doesn't matter), adds the customer's info (CC number + internal code not available to the merchant) and creates a hash that is then included with the transaction record.

No need for complete security. Just to eliminate the current situation where using a credit card for purchase means the customer has to provide the merchant with info that can be used by whoever has that info to impersonate the customer and make other transactions. Anything that avoids this can then be insured against fraud at rates that are negligible compared to what is happenning today.