Hi, What I mainly understand is that a standard "audit" current costs several $10000 which CAcert can't afford; that browsers' policies are not so well defined; that Konqueror is just blindly following IE and Mozilla; so to sum up: that a lot of things stand against the creation of a certificate authority based on a web of trust rather than money.
I can't accept arguments such as "it's not pre-included" from people who support an OS that is essentially never pre-installed. Similarly restricting the problem to a money issue is like being OK with gratis student licenses from a priorietary OS vendor. Savannah isn't the only free-software-related website that supports CAcert.org. See for example https://www.april.org/ CAcert is also the only certification authority that makes people _think_ about what trust is, which can't be more in sync with the educational purpose of Savannah. Cheers, -- Sylvain On Tue, Oct 07, 2008 at 06:40:57PM -0500, Karl Berry wrote: > Hello savannah hackers, > > Giuseppe (cc'd) added CAcert to the root certificates in the last IceCat > release primarily because of savannah starting to use it. Reed Loden > (cc'd) raised several concerns about CAcert. Messages appended below > (one from Reed, Giuseppe's reply, Reed's reply). > > Reactions, please? > > Personally, with my (very small, granted) savannah hat on, I think the > problems Reed is pointing to are pretty significant, and savannah would > be better off with the other certs that johns already purchased. > > (Of course I realize that whether IceCat includes CAcert and savannah > uses CAcert are two technically independent decisions, but it would be > nice for GNU pieces to play nicely together.) > > Karl > > > ------------------------------------------------------------------------------ > Date: Mon, 6 Oct 2008 04:35:10 -0500 > From: Reed Loden <[EMAIL PROTECTED]> > To: Giuseppe Scrivano <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: CAcert.org's inclusion into IceCat > > On Thu, 25 Sep 2008 00:10:12 +0200 > Giuseppe Scrivano <[EMAIL PROTECTED]> wrote: > > In addition, CAcert.org, already used for https://savannah.gnu.org, > > was added to the builtin root certificates. > > I'm very disappointed by this decision. Considering all the > well-documented problems with CAcert.org, this seems like a very bad > choice to be making. > > Just looking on CAcert.org's wiki, you can read some of the following > pages to find copious amounts of information on why CAcert.org isn't > ready to be used: > * http://wiki.cacert.org/wiki/Audit -- Links to various other pages > concerning CAcert.org's ongoing audit, especially their lack of a > single completed audit > * http://wiki.cacert.org/wiki/AuditToDo -- List of things left for > CAcert.org's first audit to be completed; still a long ways to go until > the audit is completed > * http://wiki.cacert.org/wiki/PolicyDrafts -- Note the lack of set > policies on how assurance is handled; how does one know that the > certificates issued by CAcert.org for a domain were really bought by > that domain if there's no set policy outlining how checks and > validations are made? > * http://wiki.cacert.org/wiki/InclusionStatus -- Links to several > places that explain why CAcert.org isn't ready to be included; note the > number of well-known browsers and operating systems who have yet to > include CAcert.org because of CAcert.org's current ongoing issues and > lack of a completed audit > > There is also time in CAcert.org's history for which the security > of its root cannot be properly accounted. What would happen if indeed > the private key of CAcert.org were to be leaked out? People could > create SSL certificates for any domain they liked, and they would > all be accepted by IceCat without any regards to their validity. > > Also, CAcert.org has issued both assured and unassured SSL certificates > from the same root, which is insecure and highly not recommended. This > is one of the main reasons Ubuntu refused to add CAcert.org's root back > when it went through discussion in 2005. I'm not sure if CAcert.org is > still issuing certificates this way, but just the fact that they have > done it at some point in time is worrisome. > > I believe you're doing a disservice to IceCat's users by including a CA > root that hasn't been properly vetted and whose root cannot be > accounted for for long periods of time. Users put trust into their > browser's CA root repository that the SSL certificates they encounter > will have been properly vetted for a certain level of quality. By > adding CAcert.org with other vetted roots, you lower the quality of the > other roots in the browser's CA root repository, as users won't be able > to know who exactly they can trust. > > If you're looking for free or cheap SSL certificates, CAcert.org isn't > the only option out on the market. I do know that StartCom's StartSSL CA > offers free class 1 DV SSL certificates, and there OV and EV > certificates are fairly cheap, too. The StartSSL CA root has been > properly vetted and audited, so it can be trusted just as much as a big > name such as VeriSign. > > Once CAcert.org completes its first audit and meets the basic > requirements of policies such as the Mozilla CA Certificate Policy > (http://www.mozilla.org/projects/security/certs/policy/), then I'm sure > you'll have no problem getting CAcert.org's root added to the > repositories of many browsers and operating systems. Until then, I > believe you should remove the root from IceCat so users can remain > secure and regain the feeling of assurance that by going to a site > over SSL, they are indeed visiting the actual site and not a site > using a fraudulent SSL certificate. > > I hope you will take the above information with an open mind and do > what is best for the safety and security of IceCat's userbase. > > ~reed > > ------------------------------------------------------------------------------ > Date: Mon, 06 Oct 2008 13:20:17 +0200 > From: Giuseppe Scrivano <[EMAIL PROTECTED]> > To: Reed Loden <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: CAcert.org's inclusion into IceCat > > Hello Reed, > > Thank you for pointing this problem out, but I think some points were a > bit exagerated, how we can say the private key were to be leaked out? > > Differently from other CAs their source code is GPL'ed and you can get > it here: http://www.cacert.org/src-lic.php. > >From my point of view, it gives users more freedom as you can look > directly at its source code and how it works, do you know of any case > that CAcert showed to don't be trustable? Are audits really so > important when the software they use is Free? > > I agree with you that the first goal of a SSL certificate is to make > sure the site you are visiting is really what you requested and safe > browsing for IceCat users is a very important thing. > On this ML we discussed the possibility to treat self-signed > certificates differently than Firefox but now I disagree with this idea > because I consider the SSL connection itself in second place to be sure > the resource you got is exactly from whom you wanted. > > Surely I am going to consider it with an open mind, I think to don't > have prejudices of any sort :) > > Regards, > Giuseppe > > ------------------------------------------------------------------------------ > Date: Mon, 6 Oct 2008 14:18:14 -0500 > From: Reed Loden <[EMAIL PROTECTED]> > To: Giuseppe Scrivano <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: CAcert.org's inclusion into IceCat > > On Mon, 06 Oct 2008 13:20:17 +0200 > Giuseppe Scrivano <[EMAIL PROTECTED]> wrote: > > > Thank you for pointing this problem out, but I think some points were > > a bit exagerated, how we can say the private key were to be leaked > > out? > > I don't think it's that much of a stretch to consider the implications > if CAcert.org's private key were to get out. It's publicly known that > CAcert.org has had times in its history where the security of its root > cannot be verified. They are working to correct these problems by > moving to a new secure datacenter to house the private key(s) and the > CA root itself, but until they get to a point where they are 100% sure > that their root is secure and their private key(s) haven't been > compromised at any time, CAcert.org should not be added to the CA root > repository. > > Do note that I mentioned many other problems besides just the possible > issues concerning CAcert.org's private key. Please re-read my mail and > consider all the different issues at hand here. > > > Differently from other CAs their source code is GPL'ed and you can get > > it here: http://www.cacert.org/src-lic.php. > > From my point of view, it gives users more freedom as you can look > > directly at its source code and how it works, do you know of any case > > that CAcert showed to don't be trustable? Are audits really so > > important when the software they use is Free? > > Just because CAcert.org's source code is GPL'd doesn't mean it's any > more secure. I could set up a CA myself, and if I don't protect both > the hardware and the software (including the operating system) of the > machine(s) that host my CA's private key, it does me no good that the > CA-specific software is GPL'd. Having one package "secure" on a box > doesn't mean the other thousands of packages used to create that box > are secure, too. Free software != always secure. > > > I agree with you that the first goal of a SSL certificate is to make > > sure the site you are visiting is really what you requested and safe > > browsing for IceCat users is a very important thing. > > On this ML we discussed the possibility to treat self-signed > > certificates differently than Firefox but now I disagree with this > > idea because I consider the SSL connection itself in second place to > > be sure the resource you got is exactly from whom you wanted. > > I would hope you wouldn't ever make self-signed SSL certificates treated > as trusted by default. I would consider that even worse than adding the > CAcert.org root, as anybody can create self-signed SSL certificates, so > your users would never know if a certificate is truly valid for the > site they are visiting. Firefox 3 did a great service to the Internet, > imho, by making SSL errors more difficult to get around, as sites need > to use valid SSL certificates that are configured properly. Users > shouldn't be trained to just ignore warnings and click-through anyway. > > SSL certificates are more than just security (encryption). They also > imply a level of identity (validity), which Firefox 3 has tried to make > better understood by users so that the different levels of SSL > certificates can be treated differently depending on their uses and so > that security is put above anything else, including ease/accessibility. > In today's world, security should be at the top of our priority list. > > > Surely I am going to consider it with an open mind, I think to don't > > have prejudices of any sort :) > > I'm glad you're considering this with an open mind like I ask, but > please make sure you consider all the problems CAcert.org currently > has, not just a chosen few. I really do believe CAcert.org will get to > the point in the future where it can be trusted and widely used, but > now is not that time. CAcert.org still has a long way to go until it > has proven its security and can be trusted as much as a normal CA. > > ~reed
