Since the Thawte Web of Trust was shut down three days ago, the only remaining Web of Trust seems to be CAcert. I'm wondering, that the community project is not included in Fedora's ca-bundle.crt right now.
Using the CAcert certificates, you e.g. can sign and encrypt your e-mails by using the S/MIME standard or use the power of SSL certificates for HTTPS. Without the root CA of CAcert, the path is broken and clients claim about an invalid certificate etc.
Thus I opened [https://bugzilla.redhat.com/show_bug.cgi?id=538219 Red Hat Bugzilla #538219], but the suggestion was refused, because the package maintainer only wants to rely on Mozilla and their doing. Unfortunately, the Mozilla guys didn't manage it for years now to get CAcert included into Firefox - other distributions ignore Mozilla upstream at that point and simply include CAcert themself. But the Fedora package maintainer doesn't want to do the same.
At the moment, Mozilla seems to ship lots of old root CAs from ancient times where it was called Netscape and you just had to put money on the table to get your root CA included. But we are Fedora, not Mozilla. We've "first", "freedom", "friends", "features" in our F. We even don't include our Fedora CA which unfortunately causes same trouble to our Fedora users. And in fact, CAcert is one of the open and community CAs.
I don't see any good reason to not include the CAcert CA root certificates into Fedora's ca-bundle.crt. CAcert is definately known to be good and it is the only real and remaining Web of Trust out there right now. Why don't we want to have this issue solved (technically it's pretty simple, I've a working patch attached to the bug report) and another nice feature in Fedora?
And now I would like to see a FESCo voting with a resulting decision here...
https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 {{{ Ian Grigg 2007-04-26 14:15:01 PDT
I've just been made aware of comments on this bugtrack that deserve some response, apologies for the delay.
As brief as I can make it: in December of 2005 I took on the role of Independent Auditor of CAcert's Certificate Authority. This task is guided by David Ross's Criteria ("DRC"), mentioned earlier by David Ross himself, and earlier pre-approved by Mozilla for their purposes.
Around June 2006, the audit process discovered severe imbalances in the contractual relationships between CAcert, its user community, Assurers and the world at large, as found by DRC. In October 2006, server issues arose which caused a difficult migration, still on-going. These also do not meet DRC.
Although these combined issues are being worked through, they caused CAcert to realise that it had outgrown its ability to manage as a tight, developer-driven open source organisation. Although the community is very keen, and the product is very valuable to its users, it now needs a stronger and broader management structure.
In December 2006, I therefore suspended the audit until that could be put in place to handle the difficult international responsibilities. Until resolved, CAcert is formally not seeking access to root lists, partnerships or the like, at the current time. This includes the list managed by Mozilla Foundation. Until CAcert's many tasks are complete, everything is in a "holding pattern" including any addition to browsers.
I can observe, but not promise, current progress: Members of the Association and others are working to meet the requirement for management over the coming months. Work is ongoing on the server transition, and announcements may happen on that.
For all CAcert's promise, the audit remains a serious process and a difficult hurdle. It works to a criteria that is objective and repeatable. The result is intended to be reliable and comparable. We may have our comments to make outside, but inside, we have a defined task. It is up to CAcert to do what is required, and they will get there in due course, or choose another path.
In the meantime, there is no point in pressuring Mozilla on the issue. Better if you wish to help, join CAcert as a user and contribute on their large task list.
Ian Grigg, Independent Auditor for CAcert's CA. }}}
We should fix things so that it's easy to install new CAs. The current setup where you have to append to a file which is shipped in RPM is crap.
We should at least be able to add a package which contains new CAs, with a {{{%post}}} script which rebuilds the CA file used by '''all''' of NSS, GNUTLS and OpenSSL. I believe Debian has something which at least ''attempts'' this, although it seemed fairly half-baked last time I looked at it.
Then perhaps we can ship a {{{cacert-ca}}} RPM, and people can ''choose'' to install it.
Unless CACert themselves have changed their stance since the above quote, I wouldn't be happy with installing it by default.
https://bugzilla.redhat.com/show_bug.cgi?id=466626 "Need a simple tool to configure CA certs"
To be clear, the pertinent question to address here is not "should we include the CACert CA", but, "should we, the Fedora Project, be making decisions on what CAs to include."
I strongly believe we should not for the reasons set out in the bug.
I agree, we shouldn't be making those decisions. We should be leaving them up to the admin.
But currently we '''do''' make those decisions. We ship the list of 'known' CAs as a monolithic text file which the admin can't sensibly replace, and also as a hardcoded array in a library!
We need to provide a way for admins to manage CAs, as set out in bug #466626. And then you're absolutely right that the question of ''which'' CAs to include is not one that we should be answering.
While we should of course allow admins to customize the list (and are failing at it, it seems), it is surely our job as distributors to select the '''default''' set of CAs to include.
kkofler: Perhaps, but while the CAcert folks themselves are saying ''"don't do it; we're not ready yet"'', that particular decision is fairly much a no-brainer.
Much as I would like it to be otherwise.
Sure, it would be great if we could provide admins better fine-grained control over the root CA list, I don't disagree with that or much in bug 466626. But that is orthogonal to this issue. Regardless of whether we do that we will still have to provide a default list of CAs.
If you think we, the Fedora project, should take on the job of deciding and vetting the default list of CAs, then you also need to decide on a CA vetting process. Or do you not think we need one? Maybe we should just include any cert requested by anybody who files a bug? After all, what's the worst that could happen?
Well, the worst that could happen is that any use of that CA bundle makes SSL completely useless, because any random idiot can get their cert trusted by default.
I think you are both grossly underestimating the complexity of this issue. Go and look at the Mozilla CA vetting process: http://www.mozilla.org/projects/security/certs/policy/ and follow what they do in the community. It is an open process. To suggest that we would want to do anything less than what they do in Mozilla is absurd. To suggest that we have people with the competence, time, and motivation to duplicate the Mozilla process is also absurd. So it is very simple to conclude that outsourcing this process to Mozilla is exactly the right thing to do.
Joe, I agree entirely that we can't start vetting CAs, and we can't ship with cacert enabled by default. Ultimately, the response to this ticket has to be ''"no"''.
I disagree slightly when you say that bug 466626 is orthogonal to this issue.
Fixing bug 466626 would allow us to say ''"Sorry, we can't do that by default but you can easily just install a cacert-ca package and get what you want"''.
Instead of the current response which is ''"Sorry, you can't easily do that at all"''.
So it's the constructive way to say ''"no"'' to this particular request -- and while it may be ''technically'' orthogonal, in this context it is quite relevant, surely?
BTW, wasn't there some licensing issue with the CAcert root key? Or has that been resolved since? If we can't ship the key due to licensing, this whole discussion may be moot anyway.
The review ticket is at https://bugzilla.redhat.com/show_bug.cgi?id=474549. It's been some time since it was updated so it's somewhat difficult to tell if that bug reflects the current state of affairs, but earlier this year it was certainly blocked due to license issues.
So, whats the status here?
I think:
So, should we close this?
Closing this now.
Login to comment on this ticket.