Self-Regulating SSL Certificate Authority?

bcg asks: "It has come that time again to renew some of my SSL certificates and part with substantial amounts of cash. This has got me thinking - why should we pay large amounts of cash for authorized certs when so little is done by the companies issuing them? Sure they get you to send them a copy of a business certificate but how does this prove the character of those running the SSL server? What ideas can we come up with for a self-regulating certification authority? Could we set something up along the lines of the many free DNS servers around but use it to authenticate SSL certs?" We last touched on this subject in October, when someone was searching for cheap SSL certs. We've also discussed why certs are so expensive. Why not take it one step further and discuss ways of making and authenticating our own certs for free...or as close to free as possible?

Comments

Character?

[Anonymous Coward]

>Sure they get you to send them a copy of a >business certificate but how does this prove the >character of those running the SSL server?

They aren't supposed to be verifying your character, they verify your identity.

Free SSL Certificates..

[dev_sda]

Personally I see very few reasons why these should not be obtainable openly.

All that a Trusted CA issued certificate says to me is that the potential scammer had the money to buy an SSL certificate.

I've got it!

[DrFrasierCrane]

Want them cheap? Let the GOVERNMENT handle SSL certs! After all, they're already handling drivers licenses, social security numbers, and ten kazillion other things that are supposed to prove that you are you, why not just give you a cert, too? For a small government fee, of course.

Chain of trust

[juancn]

I think the issue is how we build an entity that we can all trust.

Basically the security behind SSL certificates (and all certification technologies) is that you trust the CA (the root of the certificate path).

Commercial companies are trusted because they would go out-of-business if they lost your trust. So basically you trust in the fact that they want to make money.

So here is my point, besides financing and all the other issues, how do we establish a chain of trust?

Re:How about Free?

[Sonicboom]

Just self-sign a certificate. Truly, if it's not signed by some big name registrar, most internet users (IE of course) will get messages notifying them that it's not a "trusted" certificate anyways.

Self-signing is ok - but if you work for a big company and/or a financial institution - a CA is like an insurance policy. True - most end users don't know what a CA is, let alone know how to tell if one's legit.

The last dotcom I worked for bought CAs for liability and safety reasons - they were an online bill presentation and payment company.

Ri-i-i-i-ght

[apankrat]

And how would I know that the content of some online store that sends me a self-signed or home-brewed-CA certificate is not entirely faked by man-in-the-middle credit card # collector ?

And while you are 'thinking web, not hierarcy' also set aside some time to think how you would be building that web in first place. In particular - how you would be establishing trust with comletely foreign parties.

It's simple.

[mindstrm]

Nevermind all the other uses for ssl certificates.. if you are referring to secure web sites, which you probably are, the reason we don't all make our own is because the browsers will whine about not recognizing the CA.
This is percieved to turn customers off... so you pay up so things are smooth.
That is the real reason.

If you are talking about certs for vpn stuff, etc.. there is no reason to go with verisign or anyone else.. by all means, make your own. All you need is openssl.

DNSSEC is usually the right choice

[billstewart]

DNSSEC isn't widely deployed, but it's the right identity/authentication model for many of the reasons people want certs. Unlike the "Produce Lots of Official-Looking Documents" model of identity, which says that Example, Inc. is the real owner of a certificate, and lets Example use the cert to sign any web site they want, DNSSEC uses the "People Who Give You The Domain Name Sign You A Cert" model, which lets whoever owns the domain name example.com certify that you're connected to a web server at the real example.com or www.example.com.

In general, there's a lot of confusion about Public Key Infrastructures, partly because of the big gap in the middle of "1. Write Marketing Hype!! 2. ???? 3. ???? 6. PROFIT!!" chain, but mainly because there are different ways to answer questions about "Who's certifying whom or what to do what or be who or what?" which lead to different applications and solve (or fail to solve) different business problems. One major effort to address this systematically is the IETF SPKI Simple Public Key Infrastructure group, much of which is based on the work of Carl Ellison and Ron Rivest (RFC2692, Requirements, RFC2693, Theory.) It turns out that, while the "Some Authority Certifies that You have Documents with your True Name" model that's popularly used is often useful, it's often not the right model, and there are often more useful relationships, such as the DNSSEC authentication used for web sites and email.

A clarification

[Elentar]

In addition to establishing identity, certificates also allow the transmission of securely (for now) encrypted data. This is the feature everyone wants - the identity aspect is just something for Verisign to hype.

Self-signed certificates are ludicrous - it takes only a few moments longer to create your own CA (certificate authority, what Verisign is) and issue yourself a certificate. Then just link incoming clients to the CA certificate, which will be added to their CA list if they accept it, and after that your site will be free of certificate warnings.

Any benefit that 'root CA' lists may have had has been overridden by uninformed sysadmins. Too often are servers moved to new hostnames or domains, or certificates forgotten to be renewed, etc.

Users trust you to take their data and charge their credit cards, protect their personal information, send them material by delivery and provide information that is true. Why, then, wouldn't they trust you to generate a certificate yourself?

As mentioned above, the endorsement of an arbitrary company means nothing, but responsiblity and security awareness of sysadmins means everything. Owning a credit card does not prove the latter.

-Elentar

SSL should not require CA

[rjamestaylor]

Sorry, but most people don't use SSL for establishing the legitimacy of a ecommerce site, but rather to encrypt the communication with an ecommerce (or other SSL-using site, like a whistle-blowing) site. No one cares that NamathNose.com is really NamathNose.com--they want to be sure some /.'er managing the ISP's pipe between their computer and the ecommerce computer isn't trivially reading the bits travelling said pipe.

We need to divest SSL from CAs. Encryption should be CA-less. If a user and site want to require identification securely, then there should be a separate way (or optional way within SSL) to accomodate that.

It's not the data models, it's the processes

[Gerry Gleason]

Not being familiar with DNSSEC, I can't really comment on the specifics, but having done some serious PKI work for a secure messaging system a few years back I have a pretty good grasp of the issues. The bottom line is that what is important are the physical processes at the roots of the system and the software processes to support it.

What many people commenting on this story fail to realize is that the Certificate Authorities (CAs) are guaranteeing the integrity and security of their process, and not so much the identity of the person or entity applying for the certificates. In our messaging system, we had set up our own CA to issue personal certificates signed by signing certs that we bought from verisign. Since non-repudiation was an important feature of our messaging system, we did not rely on Verisign to verify identities for personal certs. Typically, a company would contract for us to provide personal certs for their people, and they would be responsible for connecting people with certs.

The idea of connecting site certificates with the issuing of domain names is a good one because the organization issuing the domain names already has a relationship with the owner of the name. This seems like the important link for site certs, and since it represents the potential for additional profits for the issuing organization, I would think they would jump on it. Of course, that's probably part of the problem as well, that nobody wants to pass up the potential revenue, so it is hard to set up the necessary relationships.

That said, it should be clear that it wouldn't be that hard to create a 'public' CA, but it couldn't be free either. When this came up before I outlined how it could be done in a comment, but how would you know you could trust this. I could create certs for myself and my friends, but who else would trust it. It isn't that hard to add new root certs to most browsers, so there is no reason you couldn't do this for your company or organization. If more organizations were actually using client certs to authenticate, it probably would be worthwhile to create a cheap, but secure, public facility.

If anyone has the persistance to actually make this happen, I would certainly be open to helping design the processes and maybe write some software. It really is an excellent idea. Ultimately, I would consider it a complete success when the root certs are pre-loaded into most common browsers. It is completely doable, and although there are important details to get right, it isn't really all that complex.