Free Certificate Authority Unveiled by Aussies
SonOfGates writes "Well, the Aussies have invaded Boston but at least they're not throwing tea into the harbor. AU-based nonprofit CAcert Inc has spent the last few days at USENIX '04 registering new users by the truckload. They bill themselves as a 'Community-Based CA.' Could this be the begining of a true 'open' certificate authority? See the O'Reilly story and press release."
when Microsoft released that update for IE that included lots of new CAs? Anyone think this one will be included in the next one? My guess is no, judging from Microsoft's general resistance to anything open.
;)
But, we might be surprised. Opinions anyone?
ps. Maybe they should patch the browser first
bash: rtfm: command not found
I'm sure Mozilla/Opera might, but what about Microsoft? If Internet Explorer doesn't support it's unfortunately not very useful.
The mythical "web of trust" we were supposed to have in Verisign/Thawte/etc... is finally comming true in a NON-PROFIT entity.
Too bad this cert isn't defaultly trusted by IE/FireFox.
Interesting side note: when I recieved the registration email from them, Outlook 2003 (yeah, I know...) marked it as "junk mail".
-Wes
Many ISP's and low-budget group have self-signed certs. They're easy to make. Hopefully this project will make it easier. I have quite often seen sites with a self-signed cert and another page giving the fingerprint of the cert. Most vendors allow these, but they aren't "trusted".
The only reason the big companies charge so much (their claim, not mine) is the insurance they provide, and the fact that they are "trusted" by the various vendors.
Any new group wanting to be a trusted CA will face the liability issue -- if one of your customers sues you, even if you try to disclaim all liability up front, you will still face massive court fees. Even if you won in court, you would lose financially if not insured.
There is no technical or logistical problem with setting up a Free (and free) common-geek's CA, the problems are entirely legal ones. I know because I looked into it right after SSL came out. It looks like a good business plan, right up until someone takes you to court.
Thank you for your support.
While I normally think the government should keep its nose out of most places, I think this is one place where the goverment could actually do some good. Just like many states and goverments proved offically accepted picture IDs to individuals, I think they could easily set up a service to provide offical digital IDs to all the citizens. Companies like Verisign may still have a role in providing corporate certs, etc, but I think the goverment is the best way to provide a universally recoginized digital ID to everyone.
The whole notion that a Cert authority is needed is essentially bogus in my opinion. We've been rolling our own certs for years for all but the main e-commerce web servers. Who wants to pay the outrageous extortion fees Verisign/Thawte charge and jump through the goofy hoops? I bite my lip and do this every two years for the main web server just so my clients don't totally (unnecessarily) freak out at the prospect of a dialogue box popping up in SSL mode warning them that Microsoft's "paranoia-protection-money" wasn't paid-off.
The Cert authorities are a joke. We registered one CA with Verisign with virtually no documentation, and another time, when renewing an existing, different cert, they demanded everything short of a blood test for "authentication." It's nothing short of criminal considering they charge $200+ for something that takes 10ms to generate that they make people wait weeks for, and in no way guarantees superior security, and they'll make certs for anyone with money so the identity checking is BS and moot.
I'm all for a free certifying agency, but you can also roll-your-own with OpenSSL.
Note: If you plan to use these certificates with Internet Explorer, Outlook, or Outlook Express then generate the certificate from within Internet Explorer. They can't be sucessfully imported into Internet Explorer. Believe us, we've tried...
-Wes
Somehow I don't feel all that secure when the site went down in 3 minutes...
"I say we take off, nuke the site from orbit. It's the only way to be sure."
I think the key to disrupting IE is by creating things it doesn't or won't support. It can't be done quickly, I don't think, but slowly, as the browsers merge in their usefull and techs that disdain MS help ignorant users to install and use them, MS can be made an equal player. Instead of a dominate force that will eventually control the US Media by holding the power of the infrastructure.
We are one consciousness experiencing itself subjectively. Back to you with the weather, Bob!
This is one of those things we all say to ourselves "they should do this," yet it never happens. I'm really glad to see this. I can't wait until I can start recommending clients to them and supporting them with large (yet still much cheaper than Verisign/Thawte!) donations. :)
Does anyone else find it somewhat offputting that they include links to both validate their XHTML and validate their CSS on the bottom of their homepage, yet both return a number of errors stating that their page is neither valid XHTML nor uses valid CSS?
Even more oddly, for a brief instant when I went to their homepage, I got a default Apache index listing, rather than their homepage. It included links to things such as their PHP MyAdmin directory, a number of PHP files, and three zipfiles named Bruce-someversionnumbers.zip.
I don't see what everyone is crying about certs costing money for. Seeing as how i've setup online shops for several people using certs, I think for what they do, the cost is justified.
Not just anyone can get a CA cert. You have to be a business, I know verisign wants a copy of your business license, ect before they even issue you a cert.
Now we got this "open CA". Who is going to check if these are legitimate businesses? Will there be any checks done at all, or will it just be "by the truckload" as the headline said?
I'm all for saving a buck as much as the next guy, but when I shop online, knowing that the cert came from a trusted source that actually checks if it's issuing a cert to a legitimate business like verisign or thawte puts my mind, as well as the minds of a lot of others.
Verisign acquired Thawte in late 1999. Though they acknowledge the fact on their corporate website, they don't exactly make it obvious they no longer compete with Verisign.
No infrastructure? No talking to servers? Que?
Without CA's and revocation information, SSL-style (RSA) public key infrastructures are useless. That means every client needs access to recently updated and TRUSTED revocation lists to make sure that no cert's have been forged or stolen. Every meaningful SSL client should periodically verify that any server certificates it uses are and remain valid. Using the CA's public key is absolutely NOT sufficient.
I think you're forgetting the part about actually verifying the authenticity of what they're signing.
IE, If I send them a certificate signing request with my public key and a name of George W Bush on the CSR, are they just gonna go ahead and sign it and give me a certificate stating that I'm George W Bush?
Certficate authorities usually require you to provide them with proof of your identity, like faxing you a driver's license, birth certificate, buisness license, trying to contact you at the stated address and phone number, etc... if they didn't do this, they wouldn't be very useful CAs... the certificates they issue would be meaningless.
Of course, this is not to say that the expensive commercial CAs are trustworthy simply because they charge money... not at all. But to be an useful CA you need to have the manpower to verify the stuff people ask you to sign. I wonder how this free CA will accomplish that.
Here's a summary of a proposal I wrote for canadian provinces...
The Governor General's office acts as the root CA for Government Ministries & Crown Corporations and Professional Associations.
Any professional association (Bar Association, College of Physicians & Surgeons, Engineers, etc) acts as a CA for it's members and corporations working in their field (Law firms (lawyers, paralegals, legal secretaries), Medical Clinics (Doctors, Nurses, X-Ray Techs, Appointment Clerks), etc)
Certified Accountants act as a CA for Corporations, Societies, Partnerships, etc.
The Notaries public act as a CA for individuals.
Denmark has free digital signatures for all citizen, for use in email, to sign in on sites, etc...
URLs:
- http://www.digitalsignatur.dk/
- http://privat.tdc.dk/digital/
(both in Danish, though...)
The technicalities are run by the largest phone company/ISP, TDC, but otherwise it's fully a government thing.
Exactly how many certificates have you seen revoked? And how many of these revocation lists are going around? I agree that the implementation of the certs is screwy, since basically it means nothing at this point other than the fact that you are communicating over SSL. Basically from a browser standpoint the implementation of certificates is completely worthless since the authentication checking is just not there. The X.509 cert's were originally designed to completely authenticate that you are talking to the host/person you intended to. Since browsers currently do absolutely nothing but a check vs. the public CA key basically any cert the CA issued regardless of status (other that those that have expired with time) are complete valid certs. They could have been forged, stolen, or otherwise abused but we trust them anyway... Really a sad state of things.... X.509 revocations do exist, but since there really is no universal Public Key Infrastructure (for the non-security guru), or rather the browsers don't even TRY or HAVE A WAY to validate them in most cases they really don't mean much at all...
-Mind
Lucky for you America hasn't banned stupidity and ignorance.
Just a question, how much this is different than www.wildid.com
They require paper proof which doesn't mean that the digital property hasn't been misappropriated from its true owner. As it stands now if someone stole your server key and you wanted to use it on their own box they can, and you cannot revoke it and have your CA reissue your cert the way it should work. Sure, the user of that site gets a browser message but big whoop... people are used to pop ups and just click shit away that they don't care to see.
This physical paper trail does nothing to increase the security of the browser, it only works to increase the security of the information the CA has. Someone can forge documents and open up a site in your name and since you cannot "revoke" a cert there is no way for you to shut them down once the process is completed. All it takes it a little bit of letterhead, a borrowed ID, and some other (possibly faked) documentation. The last time I got a cert I lied about 90% of the information.. I think the only thing that was true was the phone number. Let's fact it... The CA has no authority to shut down your key once it is issued (since there is no revocation mechanism) and once you get past the screen it is game over. That basically means these certificates are worthless for identifying people since a particular cert doesn't identify a particular host or person since they are never EVER revoked... These companies are primarily concerned with making money rememeber.... Too much scrutiny is an empty wallet... It is not in their interest to turn you away... (you are a guarranteed $200 every 1-2 years, after all)
If there was a good PKI that all the web browsers in the world could plug into this wouldn't be a problem at all. But these browser guys are competing and patenting, and I doubt it will ever happen.
- Mind
SSL certificates assure two things:
1) You communications are encrypted and can't be interecepted in transit. These days this is a trivial thing and can easily be provided with a self-signed cert.
2) The identity of the site owner has been verified. The trusted certificate authority has taken some measures to assure that the site has been authorized by the entity named in the certificate. This is not trivial.
Without #2, it's not too hard to set up a fake site and hijack someone's traffic. You can then collect usernames and passwords, or distribute false information. Imagine if someone uses a BIND exploit to take over your ISP's DNS servers and reroutes yourbank.com to a fake site. When you pay for a certificate from a trusted CA, you're paying for #2. If you don't care about #2 for your purposes, then you can act as your own certificate authority.
My question is, since (currently) IE is the dominant browser, the value of this service is going to depend upon whether or not this new CA can be designated as "trusted" by Microsoft.
We know this ultimately comes down to how much Microsoft would charge for this certification. Does anyone have any idea what the costs are? I imagine it would be some sort of subscription arrangement where you have to pay in perpetuity to Microsoft in order to not have your trusted status revoked. But how much? And would Microsoft let an open CA even exist in the first place?
For example, see the TrueSite Relying Party Agreement. "The Service is provided on an as-is basis without warranties of any kind".
Even Verisign's Relying Party Agreement, while it does offer some warranties, has a complicated scheme for weaseling out of Verisign's obligation to verify the certificate holder's identity. The relying party agreement refers you to the CPS Section 11, says "Issuing authorities (and VeriSign, to the extent specified in the referenced CPS sections) warrant and promise to ... perform the application validation procedures for the indicated class of certificate as set forth in CPS Section 5, Validation of Certificate Applications." There, Verisign says "The IA shall confirm that ... the information to be listed in the certificate is accurate, except for nonverified subscriber information (NSI)." The linked definition of "nonverified subscriber information" is "Information supplied to a certification authority as part of a certificate application". So Verisign doesn't actually stand behind any of the information in their certificates.
This is much weaker than a signature guarantee by a commercial bank, where the bank guarantees to other parties that the person was properly identified. But it costs more.
I'd like to see banks belonging to Visa International and MasterCard issue digital certificates, and require that their certificates had to be on a page that accepted their credit cards. Certificates from banks would actually be worth something.
The thing is, a email / personal cert from Verisign etc. comes with no guarantees that the signer is actually who they say they are. You could impersonate someone quite easily just by typing in bogus details.
Verisign doesn't audit you or vouch for you, so the cert is essentially worthless. It's a few bits that say Verisign touched it but that's about all you get for your ten dollars or whatever it is these days. If you want Verisign to actually vouch for you, you're looking at paying hundreds or thousands for a cert.
And after a 6 months, a year or two the cert expires and you have to start the process all over again.
A free CA is a good thing, but again it says nothing about the authenticity of the site / person who obtained it. I think that in itself would be an extremely valid reason for Microsoft to refuse to acknowledge them for anything but email. i.e. recognize the cert for email addresses, but not for SSL or signed executables.
On the small scale, PGP is a much better model. Anyone can make a key and start passing it around. You can get other people to sign the key if you want, but it's perfectly usable for crypto from the get go. Not only usable but faster too - as anyone who's tried to encrypt something large with RSA already knows. In fact extensions such as Enigmail for Mozilla are arguably easier to use than the built-in S/MIME.
On the signing front, I really wish Mozilla / Firefox would use PGP certs too to sign their XPI files. At present no one signs XPI files (reason: they're too expensive). If an XPI file were signed with a PGP key, you could drill down through the signers and reasonablly gauge the trustworthiness of the author. Hell, PGP doesn't even preclude CAs from doing business since they can sign keys just as well as the next person and charge for it.
But we have to be careful that we don't let our "wish to believe" blind us to the need for some caution here. Take at look at CACert's site. You'll find carelessness, spelling mistakes, pieces that have not been thought out. Running a CA properly requires meticulous attention to detail, and their site shows the opposite. On the very first page when you sign up, it asks for your name, date of birth, and "country". Is that country of citizenship, or country of residence?
Then there's the reliance on "government ID". If somebody presents Nigerian ID, or Dominican Republic ID, what exactly is that worth? It's not worth anything, you can bribe officials in those countries (and many others) to issue whatever official document you want. Does that mean that citizens of Nigeria can never be trusted? That's well over 100 million people in just that one country, most of whom are honest and trustworthy. It's ridiculous to exclude so many people from receiving certificates just because their bureaucrats are corrupt, and it's completely contrary to the transnational spirit of the Internet.
In conclusion, the idea behind CACert is a good one, but the people running it don't seem to be doing a good job. I hope that somebody else takes up the idea and does it better. There is no reason why there should not be more than one volunteer-based CA.
...those that produce a warning in browsers, and those that don't. Most everything else, is all the same to 99,99% of the people.
Kjella
Live today, because you never know what tomorrow brings
Quote from the article:
He goes on to describe the process of getting the root cert, hopefully, included into the Mozilla project through a Bugzilla feature enhancement request. From what I read from the article, the discussion about this is still going on.
X.509 binds names to keys; it's the name that matters in an X.509 system. But because there aren't enough bits in the human-language name to uniquely identify every entity of interest in the network, X.509 is based on X.500 naming, which mates the human-language name (common name, or CN) with that name's position in the global directory. Together they form the distinguished name, or DN.
X.500 naming, however, presumes a single, global namespace. The X.500 directory was intended to be a single directory for the entire planet providing unique, inescapable names for everyone.
Yeah, right. Like that's going to happen.
As a result, X.509 is carved into literally hundreds of local namespaces. But since we're stuck with the *name* as the principal, we have to use that X.509 name *globally*. There are multiple ugly kludges to get around the name problems as a result.
This makes X.509 complex, fragile, and difficult to deploy correctly.
But everyone (potentially) has a globally unique identifier-- the public part of an RSA key. Randomly generated, 2^42 512-bit RSA keys have a probability of colliding on the order of 2^(-429); even the SHA-1 hashes have a collision chance of 2^(-77). Keep in mind that we use 1024-bits as the default nowadays.
So if you use the public key as a name, it solves a whole raft of problems.
This is what SPKI/SDSI does. SPKI is key-centric; names are a local convenience; keys are bound to names instead of the other way around, and all names are local to that key. Every participant has a key pair. The public part is the identifier for the keyholder, and the keyholder authenticates himself simply by proving that he has the private part.
Keep in mind that the whole issue of binding keys to actual people can't be addressed by a PKI, it has to be addressed by strong key storage and access controls and is the same across for X.509 and PGP/GPG as it is for SPKI.
This is similar to the web of trust, but I don't need introducers (well-connected keys) to make it work right.
SPKI goes on to recognize that since authentication is simple, what we really need from SPKI is authorization. The whole of SPKI is intended to define a flexible method of allowing authorization *and authorization delegation* in a simple, distributed fashion. SPKI defines an authorization *language* so that authorizations can be chained *without the SPKI library knowing what the tokens actually mean*. This means that a single library can handle the permission sets of all applications. In addition, the language rules prevent all entities in the chain of delegations from being able to exceed the permissions he was granted.
Achieving the same under X.509 (using attribute certificates, for example) is next to impossible. ACs don't delegate (well, the standard itself says technically you can but you *shouldn't*); aren't truly distributed (i.e., the AC acts as a single choke point in granting permissions, which SPKI avoids), and doesn't model the way trust naturally flows in an organization of people (whereas SPKI allows you to source and pass around trusts in more natural ways).
Very cool stuff. SPKI shows up in all kinds of places. Carl Ellison's homepage provides the best jumping-off point if you want to learn more:
http://world.std.com/~cme/html/spki.html
-- Cerebus
How is this different from the Web of Trust free cert service that Thawte provides? Same notarization scheme.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."