Slashdot Mirror
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."
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
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.
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!
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.
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.
It's not a big deal. It doesn't mean anything. It doesn't offer more security ultimately.
The majority of e-commerce sites on the Internet are NOT operating under their own certs. Many sites that offer hosted shopping carts use a central SSL server operating under an umbrella cert. Nobody really seems to have noticed, so what Verisign/Thawte are selling is not something consumers really seem to care about.
However, the most common usage of SSL cert's is simply to enable encryption between two points. For this, there's nothing wrong with even a home-brew cert - validation of the cert via it matching the domain should be sufficient. A SSL cert generated by a 3rd party adds absolutely nothing to security, and it shouldn't do anything to reassure the customer/client that they're dealing with a legitimate operation.
It prevents man-in-the-middle attacks. That's the most important reason for me to use a trusted CA.
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
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."