Debian Bug report logs - #718434

ca-certificates: should CAcert.org be included?

Reported by: Ansgar Burchardt <ansgar@debian.org> Date: Wed, 31 Jul 2013 18:09:01 UTC Severity: important Fixed in version ca-certificates/20140223 Done: Michael Shuler <michael@pbandjelly.org> Bug is archived. No further changes may be made.

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Wed, 31 Jul 2013 18:09:06 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org> :

New Bug report received and forwarded. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 31 Jul 2013 18:09:06 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org> To: submit@bugs.debian.org Subject: ca-certificates: should CAcert.org be included? Date: Wed, 31 Jul 2013 20:06:26 +0200

Package: ca-certificates Severity: important I'm wondering if Debian really should include CAcert.org root certificates: The CAcert.org root certificates are only included by a small number of vendors[1]. No major web browser (Mozilla, Chrome, IE, ...) includes them by default. [1] <http://wiki.cacert.org/InclusionStatus> CAcert.org itself has withdrawn its inclusion request into Mozilla's certificate list[2] until an audit is completed. I'm not sure where the current status is recorded, but [3] doesn't look too promising. [2] <https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158> [3] <http://wiki.cacert.org/AuditToDo> I'm also not sure how well they follow current recommendations. For example, Mozilla's CA requirements[4] include that "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)" which I believe was introduces as a consequence of some attacks on CAs that relied on predictable serial numbers. CAcert.org doesn't seem to implement this, at least not in the serial number (not sure what other places to check). [4] <http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html> And last but not least: while CAcert.org publishes the source code of their system[5] (good), looking at it does not make me trust it (it causes the opposite effect)... [5] <http://www.cacert.org/src-lic.php> This probably also affects Iceweasel and maybe other browsers as well. Ansgar

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Wed, 31 Jul 2013 18:57:14 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Wed, 31 Jul 2013 18:57:14 GMT) (full text, mbox, link).

Message #10 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: Ansgar Burchardt <ansgar@debian.org>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Wed, 31 Jul 2013 13:55:46 -0500

In addition, I had an email conversation (link to thread is escaping me, at the moment) about removal due to their license statement [0] that "You are bound by the Root Distribution Licence for any re-distributions of CAcert's roots." [1]. I was convinced by others that the certificates cannot be licensed, since they are essentially mathematics, but it still bothers me that we are not following their license, which may be non-free. Apologies for a quick reply, without some essential details about the conversation - I will dig up those details, as soon as I can, and send them along to this bug. Also, I am not a lawyer, so my opinion was based on layman reading of the CAcert license. [0] http://www.cacert.org/?id=3 [1] http://www.cacert.org/policy/RootDistributionLicense.php -- Kind regards, Michael

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Wed, 31 Jul 2013 19:03:07 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Wed, 31 Jul 2013 19:03:07 GMT) (full text, mbox, link).

Message #15 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: Ansgar Burchardt <ansgar@debian.org>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Wed, 31 Jul 2013 14:02:17 -0500

On 07/31/2013 01:55 PM, Michael Shuler wrote: > In addition, I had an email conversation (link to thread is escaping me, > at the moment) about removal due to their license statement [0] that > "You are bound by the Root Distribution Licence for any re-distributions > of CAcert's roots." [1]. That conversation was in http://bugs.debian.org/687693 My recollection was that it was on a mailing list. So, that is some further reading.. > [0] http://www.cacert.org/?id=3 > [1] http://www.cacert.org/policy/RootDistributionLicense.php -- Kind regards, Michael

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 14 Sep 2013 17:18:12 GMT) (full text, mbox, link).

Acknowledgement sent to "Thomas R. Koll" <tomk32@gmail.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 14 Sep 2013 17:18:12 GMT) (full text, mbox, link).

Message #20 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thomas R. Koll" <tomk32@gmail.com> To: 718434@bugs.debian.org Cc: Ansgar Burchardt <ansgar@debian.org>, Michael Shuler <michael@pbandjelly.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sat, 14 Sep 2013 19:15:58 +0200

Hi, I recently had to read into CACert, wether they are a good and practical thing to use for https ssl certificates, with browers red warning messages and what not. During my research I just stumbled across this bugreport and like to contribute my ¢2.1 I don't think the other discussion on -legal about the CACert wanna-be license is the way here. Instead lets' focus to Ansgar's original question: Should CACert.org be included? If we go back to when it was included into ca-certificates, in 2003[0], no one asked about the security of the CACert organization itself. David Ross hadn't yet started his Checklist (aka DRC, I only found a draft[1]) CACert probably didn't know what an audit is and even if, they didn't expect to still work on it. Instead that bug 213086 turned into a popularity vote just like the mozilla bug report did over the years (as critized by CACert's own auditor). Btw, that mozilla bug was just recently closed, invalid, after 10 years. The inclusion in 2003 didn't follow any procedings to check CACert's security. The certificate of a CA only a few months old was added without a thought! By distributing, trusting the CACert root certificates you are taking responsibility. On to the audit: CACert tried often, ran internal ones and in 2008 newly created root certifcates did fail[2]. root certificates! Not something community-specific like the assurers (who could be anybody). For the lower standard of Mozilla, they failed to complete, let alone keep the schedule. I wouldn't call them a greedy bunch of capitalists like some do with WebTrust. And for sure Mozilla's has an idea what an organization of volunteers is. You must admire someone like Ian Grigg[3] for still working on the audit. Possibly against people who scream: "We don't need this, it costs money." 10 grand/year for auditing CACert, hey that's what wikipedia can raise in an hour, and what less than what FreeBSD's Security Officer raised for his summer of code[4]. Speaking of: FreeBSD did remove[5] CACert's certifcates on grounds of their Security Officer not taking the risk of distributing an unaudited CA and Debian should ask the same questions. Looking at the ca-certificates package, mozilla-sanctioned certificates make up most of the bunch, CACert is one of two exceptions, next to spi-inc.org (which I never heard of until now). It smells like double standard for those two exceptions. I sincerely do hope CACert does complete the audit, the sooner the better. Removing their root certificates from ca-certificates, one of the few places where they are actually distributed, would put pressure on them to get their act together and pass that audit. ciao, tom [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213086 [1] http://rossde.com/CA_review/ [2] first paragraph http://wiki.cacert.org/AuditToDo [3] https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 [4] Even People who want to work on making things more secure do get this sort of funding http://people.freebsd.org/~cperciva/funding.html [5] http://www.freshports.org/security/ca-roots/ PS: Sorry for sending from a mac.

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Sat, 14 Sep 2013 21:45:04 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Sat, 14 Sep 2013 21:45:04 GMT) (full text, mbox, link).

Message #25 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: "Thomas R. Koll" <tomk32@gmail.com> Cc: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sat, 14 Sep 2013 16:41:49 -0500

On 09/14/2013 12:15 PM, Thomas R. Koll wrote: <..lots!..> I appreciate you adding some good details and your thoughts to this bug report, Thomas. -- Kind regards, Michael Shuler

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sun, 15 Sep 2013 15:06:04 GMT) (full text, mbox, link).

Acknowledgement sent to "Thomas R. Koll" <tomk32@gmail.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sun, 15 Sep 2013 15:06:04 GMT) (full text, mbox, link).

Message #30 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thomas R. Koll" <tomk32@gmail.com> To: Michael Shuler <michael@pbandjelly.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sun, 15 Sep 2013 01:16:25 +0200

This already went to Michael only, sorry I kept the rest of you out by mistake. Yes Michael, facts, that's the one thing this whole issue is missing. Just read the request to add CACert into mozilla-firefox http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309564 Yes, this is was a request to do the one thing that Mozilla itself didn't want. It is like asking Dad(ian) for ice-cream after Mom(zilla) said no :D In the very last mail of that discussion madduck turning the burden of proof upside down. You shouldn't argue why not to include or remove CACert, it is CACert who has to proof rock-solid why it should be considered for inclusion. Another important aspect, which you find mentioned in the long mozilla bugreport by mozilla staff and confirmed by auditor Ian Grigg: Requests for inclusion should *only* come from officals of the CA. madduck may be a longtime assurer and have a feel for how good CACert is, but simply can't have the insight a CACert board member or auditor has. But I just found one request that was official (msg #20), Venzuela's Suscerte and I also see that in #37 you've referred them to Mozilla. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609942#20 It is a double standard that you are applying just for SPI and CACert. Oh SPI, how did that get in? By a simple question from Mike Hommey[1]: "Now, realistically, adding CACert should be enough for Lenny. Maybe SPI, could be worth, too." And madduck was happy to comply. We know nothing about SPI, how they create their root certifactes, who can issue new ones and they didn't even ask for it. Remember, we are talking root certificates here, they print passports, not fake passports but the real ones. They can print you one for google.com if they feel like it and it would be a real one. I can research a little more if you feel you need more facts before removing the CACert and SPI root certificates. KDE years ago took a policy not to include unless an audit or big browser say it's okay. https://bugs.kde.org/show_bug.cgi?id=74290#c16 ciao, tom [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309564#129 Am 14.09.2013 um 23:41 schrieb Michael Shuler <michael@pbandjelly.org>: > On 09/14/2013 12:15 PM, Thomas R. Koll wrote: > > <..lots!..> > > I appreciate you adding some good details and your thoughts to this bug > report, Thomas.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Mon, 16 Sep 2013 09:51:04 GMT) (full text, mbox, link).

Acknowledgement sent to "Thijs Kinkhorst" <thijs@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Mon, 16 Sep 2013 09:51:04 GMT) (full text, mbox, link).

Message #35 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org> To: "Thomas R. Koll" <tomk32@gmail.com>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Mon, 16 Sep 2013 11:46:05 +0200

Hi Tom, On Sun, September 15, 2013 01:16, Thomas R. Koll wrote: > But I just found one request that was official (msg #20), Venzuela's > Suscerte > and I also see that in #37 you've referred them to Mozilla. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609942#20 > > It is a double standard that you are applying just for SPI and CACert. I think you're confusing two things here. The inclusion process of the past, which was just that CA's needed advocating votes from project members. The current process is to just rely on what Mozilla does. So this explains how the certificates got here, but it's not really relevant. The question is to now judge whether CAcert and SPI should remain here, and they need not be tied together. First, CAcert. CAcert is a bit of a special case because it's the only real community CA, and in that sense very different from the other CA's, and in that sense also close at heart to the way Debian operates. I fully agree that CAcert has been less than stellar in the past on the trustworthiness area. Nonetheless, I do not perceive the current situation to have any sign of there being a real threat or risk to the model. I would be inclined to keep the status quo, as to give this sympathetic community effort, which can't "just" get itself audited, a chance. As said, I don't think we would gain significant added security in Debian by dropping it, even though there probably would be enough concerns when it would be newly added. I know, it's more an inclination than a fact-based reasoning. But this is precisely because CAcert is special and it is a fact that it operates very differently from commercial CA's. > And madduck was happy to comply. We know nothing about SPI, how they > create their root certifactes, who can issue new ones and they didn't > even ask for it. Why do you think we know nothing about it? SPI is an association very closely associated with Debian. We know a lot about SPI and its workings. Indeed there has been discussion at SPI whether SPI should be buying or distributing commercial certificates for its members, but it currently does not. We can keep SPI trusted in any case since it's inherently trusted by the project. Debian is already root on your system, so trusting them to be root but not trusting them with certificate issuance seems not logical to me. Cheers, Thijs

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Mon, 16 Sep 2013 10:45:04 GMT) (full text, mbox, link).

Acknowledgement sent to Thomas R. Koll <tomk32@gmail.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Mon, 16 Sep 2013 10:45:05 GMT) (full text, mbox, link).

Message #40 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Thomas R. Koll <tomk32@gmail.com> To: "718434@bugs.debian.org" <718434@bugs.debian.org> Cc: Thijs Kinkhorst <thijs@debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Mon, 16 Sep 2013 12:42:29 +0200

Am 16.09.2013 um 11:46 schrieb "Thijs Kinkhorst" <thijs@debian.org>: > On Sun, September 15, 2013 01:16, Thomas R. Koll wrote: >> But I just found one request that was official (msg #20), Venzuela's >> Suscerte >> and I also see that in #37 you've referred them to Mozilla. >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609942#20 >> >> It is a double standard that you are applying just for SPI and CACert. > > I think you're confusing two things here. The inclusion process of the > past, which was just that CA's needed advocating votes from project > members. The current process is to just rely on what Mozilla does. So this > explains how the certificates got here, but it's not really relevant. The > question is to now judge whether CAcert and SPI should remain here, and > they need not be tied together. So we can agree then that the inclusion process of the past, simple advocating without proper checks or an audit, was wrong? As well as the reasonable condition that the root certificate's issuer or representatives should request inclusion, not some user. On them being tied together, it wasn't my intention to say "if one goes the other has to go as well", I merely pointed that they did get into ca-certificates in a bundle and that the whole, very sensitive thing happened without much thought. I haven't read through mozilla's proceedings[0] yet but found this list of pending requests: http://www.mozilla.org/projects/security/certs/pending/index.html And SUSCERTE is on hold there. > CAcert is a bit of a special case because it's the only real community CA, > and in that sense very different from the other CA's, and in that sense > also close at heart to the way Debian operates. > > I fully agree that CAcert has been less than stellar in the past on the > trustworthiness area. > > Nonetheless, I do not perceive the current situation to have any sign of > there being a real threat or risk to the model. I would be inclined to > keep the status quo, as to give this sympathetic community effort, which > can't "just" get itself audited, a chance. As said, I don't think we would > gain significant added security in Debian by dropping it, even though > there probably would be enough concerns when it would be newly added. I > know, it's more an inclination than a fact-based reasoning. But this is > precisely because CAcert is special and it is a fact that it operates very > differently from commercial CA's. First of all: **Security needs facts**, drop every gut-feeling you have in the matter. Secondly: Yes, CACert is something special, as a community even more, but still they need to keep their private keys safe. And CACert must be able to give everyone, who distributes and vouches (and ca-certifactes is doing that) for their root certifcates, give a strong assurance that they are safe to do so. Distributing root certificates has no clear laws like selling a car does. If you were to build and operate, or even sell, a community-designed car you'd have to bow to the same laws as a commercial car manufacturer has.[1] >> And madduck was happy to comply. We know nothing about SPI, how they >> create their root certifactes, who can issue new ones and they didn't >> even ask for it. > > Why do you think we know nothing about it? SPI is an association very > closely associated with Debian. We know a lot about SPI and its workings. sorry, that "know nothing about SPI, how" was victim of my wild copyediting and should read something like "We know nothing about how SPI creates…" Do you know about how they create, store and secure their root certificates? Did they ever ran an internal or external audit to ensure this security? It is good that SPI was thinking about not issuing certificates itself, this would take the burden of an audit from their shoulders. I couldn't find any information on any audit, but maybe someone higher up Debian or SPI can tell us. I know it will look quite idiotic to remove the one root certificate that has signed the certificates for Debian, but still they should comply to the same strict rules like anyone else. You think, the SPI root certificate is distributed on a lot of servers, likely for debian's package servers as well. Are you really saying that you don't bother about wether one could get their hands on SPI root, create a fake debian certificate and mess with seriously dangerous things? It would be a large operation but the less weak points in this chain, the more secure the system is. And that's without thinking about the endless number of other applications relying on the trust ca-certificates has into the root certificates. Many applications I come accross won't accept self-signed certificates by default. Instead of trusting the SPI root, ca-certificates could include the handfull certificates for its own packages servers, they won't be root, but users can trust them slightly more and it removes the possible insecurity of the SPI roots. I wouldn't mind if a CA created their root, use that to create the set of certificates and want to give out and then burn the private key of the root. No need for an audit as the root private key would only exist mathematically. Distrusting the root and manually approving certificates issued by such a root, is how I do it personally, even though sounds a bit crazy. The fact, or rather glitch, that CACert and SPI are part of ca-certificates mustn't have a weight in a discussion about their inclusion. ciao, tom [0] https://wiki.mozilla.org/CA:How_to_apply the page on CA:Information_checklist is also worth reading [1] or build a three wheel car, they are classified as motorcycles and have rules about as same a suicide booth.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Mon, 16 Sep 2013 12:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Mon, 16 Sep 2013 12:09:04 GMT) (full text, mbox, link).

Message #45 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org> To: 718434@bugs.debian.org Subject: Re: ca-certificates: should CAcert.org be included? Date: Mon, 16 Sep 2013 14:06:07 +0200

On 07/31/2013 20:06, Ansgar Burchardt wrote: > I'm wondering if Debian really should include CAcert.org root certificates: [...] > And last but not least: while CAcert.org publishes the source code of > their system[5] (good), looking at it does not make me trust it (it > causes the opposite effect)... > > [5] <http://www.cacert.org/src-lic.php> > > This probably also affects Iceweasel and maybe other browsers as well. I actually filed this report after finding several issues in the CAcert code. There are some good ideas, for example the private key is stored on a machine not connected to the internet, and of course publishing the source code for their software is always good. However looking at the code for a few hours I found several issues, including arbitrary code injection (which should allow getting any certificate signed you want, but no direct access to the private key). One example is [1], but there is at least one more. Ansgar PS: I would prefer if discussion about the SPI certificate was kept seperate. [1] <http://git-cacert.it-sls.de/cgi-bin/gitweb.cgi?p=cacert-devel.git;a=commitdiff;h=8fa82f2cbd17e3f32a537cd405b01d6b6c623ea0>

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Wed, 13 Nov 2013 18:51:08 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Wed, 13 Nov 2013 18:51:08 GMT) (full text, mbox, link).

Message #50 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: 718434@bugs.debian.org Cc: Ansgar Burchardt <ansgar@debian.org> Subject: Re: ca-certificates: should CAcert.org be included? Date: Wed, 13 Nov 2013 10:48:36 -0800 (PST)

I'm curious what the status of this bug is -- is there a plan to remove CAcert in the next upload? As far as I can tell, the only CA certificate sources making an active decision to ship CAcert are Debian, Mageia, and OpenBSD. All other OSes/distributions that do ship CAcert by default and trust it by default[3] do so either because they're downstream from Debian (in the case of e.g. Ubuntu) or because they are using Debian's package (in the case of e.g. Gentoo[4] and Arch[5]). Gentoo seems to have no policy or rules about what's included. OpenBSD seems to have no policy, possibly other than "reasonably sane" and "We should probably think carefully" (see r1.1 in [2]). A friend of mine once complained to me that this means that webmasters who use Debian (or a Debian derivative) as their personal OS will often fall into the trap of setting up a website using CAcert, test it on their own machine, and then be surprised when users not on Debian get untrusted certificate errors. This is a pretty strong negative effect on usable security, and seems like a disservice to Debian users and other users of this bundle. Since it seems unlikely, eight years later, that CA curators who don't currently include CAcert are likely to start until they pass their audit, and Debian's CA bundle is by far the most widely-used of the bundles that include CAcert, the positive value of Debian continuing to ship CAcert's root on the grounds of solidarity with their mission seems nil. For what it's worth, I also agree with the security concerns about CAcert -- I'm a little surprised that, given the code quality of the file that Ansgar found a vulnerability in, the root wasn't immediately distrusted. The specific reason I looked at this bug was that I found myself replying to a Reddit comment advocating for CAcert's inclusion in places other than Debian, and having to explain that Debian is not endorsing CAcert's security: http://www.reddit.com/r/technology/comments/1qj1tz/http_20_to_be_https_only/cddfmz0?context=1 Debian's continued inclusion of CAcert in the default certificate store is inevitably interpreted as an endorsement of their security practices, despite the disclaimer in the package description (see also the discussion in #647848). Incidentally, GlobalSign is now offering gratis wildcard certificates for "open source projects"[6], which they define as actively maintained projects under an OSI-approved license. Between that and StartCom's gratis offering[7], in my opinion 95% of the practical use cases for keeping CACert in Debian are probably covered. [1] http://svnweb.mageia.org/packages/cauldron/rootcerts/current/SPECS/rootcerts.spec?view=markup [2] http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/cert.pem [3] http://wiki.cacert.org/InclusionStatus [4] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca-certificates/ca-certificates-20130906.ebuild?view=markup [5] https://www.archlinux.org/packages/core/any/ca-certificates/ [6] https://www.globalsign.com/ssl/ssl-open-source/ [7] http://www.startssl.com/?app=1 -- Geoffrey Thomas http://ldpreload.com geofft@ldpreload.com

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 16 Nov 2013 16:12:10 GMT) (full text, mbox, link).

Acknowledgement sent to "Thijs Kinkhorst" <thijs@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 16 Nov 2013 16:12:10 GMT) (full text, mbox, link).

Message #55 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org> To: "Geoffrey Thomas" <geofft@ldpreload.com>, 718434@bugs.debian.org Cc: "Ansgar Burchardt" <ansgar@debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sat, 16 Nov 2013 17:09:08 +0100

On Wed, November 13, 2013 19:48, Geoffrey Thomas wrote: > I'm curious what the status of this bug is -- is there a plan to remove > CAcert in the next upload? Thanks for your interest. A final decision still has to be made. However, I think enough information and arguments have been gathered by now. > A friend of mine once complained to me that this means that webmasters who > use Debian (or a Debian derivative) as their personal OS will often fall > into the trap of setting up a website using CAcert, test it on their own > machine, and then be surprised when users not on Debian get untrusted > certificate errors. This seems like an unlikely scenario, as CAcert is not enabled by default in Debian's most used browsers, Iceweasel (Firefox) and Chromium. Cheers, Thijs

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 05 Dec 2013 14:00:04 GMT) (full text, mbox, link).

Acknowledgement sent to Alessandro Vesely <vesely@tana.it> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 05 Dec 2013 14:00:04 GMT) (full text, mbox, link).

Message #60 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Alessandro Vesely <vesely@tana.it> To: 718434@bugs.debian.org Subject: Bug #718434, please leave CAcert as is Date: Thu, 05 Dec 2013 14:51:50 +0100

I find CAcert pretty useful, and it is handy to have their certificate installed by default. From other contributions to this bug, it seems their auditing, policies, or disclaimer have some issues. From a practical POV, the incidents reported by THC[0] mention different CAs, so I'd rather remove them than CAcert. CAcert's disclaimer spells the same no-liability stuff that all Debian software bears. The only real reason that we would remove that certificate is because Mozilla doesn't do it. (BTW, CAcert is not any more on the pending list mentioned in message #40.) If anything, it should made clear[er] that there is no endorsement or assumption of responsibility in distributing ca-certificates: Just like any other package, it is done on a best-effort basis. CAcert is a well known CA. Debian has historically distributed its certificate, and should not stop unless there is a serious reason to do so. Please just set WONTFIX. [0] https://wiki.thc.org/ssl#head-96dca2abae666e78fe5a0955a6548517812bdc4e Thanks Ale

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 05 Dec 2013 15:00:04 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 05 Dec 2013 15:00:04 GMT) (full text, mbox, link).

Message #65 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: 718434@bugs.debian.org Cc: Geoffrey Thomas <geofft@ldpreload.com>, Ansgar Burchardt <ansgar@debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 5 Dec 2013 15:56:06 +0100

On 16 November 2013 17:09, Thijs Kinkhorst <thijs@debian.org> wrote: [...] > This seems like an unlikely scenario, as CAcert is not enabled by default > in Debian's most used browsers, Iceweasel (Firefox) and Chromium. I believe it is: http://patch-tracker.debian.org/patch/series/view/nss/2:3.14.3-1/95_add_spi+cacert_ca_certs.patch That said, I think it is time to start discontinuing the certificate. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 05 Dec 2013 17:24:09 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 05 Dec 2013 17:24:09 GMT) (full text, mbox, link).

Message #70 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: Raphael Geissert <geissert@debian.org> Cc: 718434@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>, control@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 5 Dec 2013 09:20:42 -0800 (PST)

clone 718434 -1 reassign -1 libnss3 retitle -1 nss: Please remove CAcert.org roots thanks On Thu, 5 Dec 2013, Raphael Geissert wrote: > On 16 November 2013 17:09, Thijs Kinkhorst <thijs@debian.org> wrote: > [...] >> This seems like an unlikely scenario, as CAcert is not enabled by default >> in Debian's most used browsers, Iceweasel (Firefox) and Chromium. > > I believe it is: > http://patch-tracker.debian.org/patch/series/view/nss/2:3.14.3-1/95_add_spi+cacert_ca_certs.patch > > That said, I think it is time to start discontinuing the certificate. Aha, thanks for finding that, I was wondering if I was crazy or had misconfigured my system, which is why I didn't say anything. :-) nss maintainers: Please see the history of this bug for discussion about whether to continue to include CAcert's root in the ca-certificates package. A number of folks (including myself) believe that CAcert's security risk is too high and its benefit too low, these days. If ca-certificates removes the CAcert root, nss should presumably do likewise. I myself also think it makes sense to remove the CAcert root from nss now. For the sake of clarity, since nss adds both SPI and CAcert in the same patch, the present discussion is only about CAcert and there is no proposal to drop SPI. (See also #309564, the bug that originally added the CAcert and SPI roots to the nss package.) -- Geoffrey Thomas http://ldpreload.com geofft@ldpreload.com

Bug 718434 cloned as bug 731463 Request was from Geoffrey Thomas <geofft@ldpreload.com> to control@bugs.debian.org . (Thu, 05 Dec 2013 17:24:12 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 05 Dec 2013 19:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Geoffrey Thomas <geofft@ldpreload.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 05 Dec 2013 19:21:05 GMT) (full text, mbox, link).

Message #77 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com> To: Alessandro Vesely <vesely@tana.it> Cc: 718434@bugs.debian.org Subject: Re: Bug #718434, please leave CAcert as is Date: Thu, 5 Dec 2013 11:16:57 -0800 (PST)

On Thu, 5 Dec 2013, Alessandro Vesely wrote: > I find CAcert pretty useful, and it is handy to have their certificate > installed by default. From other contributions to this bug, it seems > their auditing, policies, or disclaimer have some issues. Their code quality also has some issues, as described in this bug report, which directly impacts their trustworthiness to sign only valid requests. Can you quantify what you mean by "useful" and "handy"? If your specific use case involves free SSL certificates, there are multiple other providers of such things in the Mozilla-distributed root set, that are linked to by the above ticket. Server admins who currently use CAcert will find it more useful to switch to such a root, regardless of whether Debian drops CAcert, because then their site's security can be verified on other platforms. If there are use cases for CAcert other than the fact that their certificates are free-of-charge, I'd be curious to know that, but I'm under the impression that that's basically the only driver these days, and my arguments in this thread are mostly based on that. > From a practical POV, the incidents reported by THC[0] mention > different CAs, so I'd rather remove them than CAcert. I believe all those roots were either removed from the Mozilla set, or rekeyed. For what it's worth, I'd be happy to see Debian be _more_ conservative than Mozilla in what roots it includes, just not less. Note that CAcert has not rekeyed after the security issue that Ansgar found, and it's really the response to that issue (and lack of publicity) more than the issue itself that makes me uncomfortable with them as a default trusted root. Incidentally, that issue probably would have gotten widespread attention if CAcert was in the Mozilla list... Debian doesn't have the ability to generate the same sort of public outcry for roots that it's locally including. > If anything, it should made clear[er] that there is no endorsement or > assumption of responsibility in distributing ca-certificates: Just like > any other package, it is done on a best-effort basis. I actually do think that's the right policy for Debian, but in the form that Debian should pass the trust questions off to an entity like Mozilla who is willing to make those endorsements (since the only other real way to make "no endorsement" clear is to make no roots trusted by default). That's exactly what FreeBSD did: http://www.freshports.org/security/ca-roots/ "The port is deprecated since it is not supported by the FreeBSD Security Officer anymore. The reason for this is that the ca-roots port makes promises with regard to CA verification which the current Security Officer (and deputy) do not want to make. "For people who need a general root certificate list see the security/ca_root_ns, but note that the difference in guarantees with regard to which CAs are included in ca_root_ns vs. ca-roots. The ca_root_ns port basically makes no guarantees other than that the certificates comes from the Mozilla project." -- Geoffrey Thomas http://ldpreload.com geofft@ldpreload.com

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Fri, 06 Dec 2013 18:33:04 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Fri, 06 Dec 2013 18:33:04 GMT) (full text, mbox, link).

Message #82 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 06 Dec 2013 12:28:36 -0600

I just wanted to include a reply on this bug that I have been reading the responses as they have been posted. I appreciate the feedback and I'm still pretty torn, to be honest. #1 - Debian does not distribute CAcert's web site code, so while the question about its quality is technically irrelevant, it is still a concern for the service. Since that code is open source, someone found something that can be fixed. Cool. Can the same be said for every CA? I think not. And I imagine there are multitudes of security issues that could be found in any CA's web service, if the code was public. Doesn't that make CAcert *more* transparent? Isn't this the whole point of OSS? #2 - All CAs included in ca-certificates are available to have the trust turned off. If you have a concern about a particular CA and do not trust them, disable that CA. #3 - Yes, other linux/bsd distributions have removed CAcert's certificates. Should Debian? Perhaps. Perhaps not. I'll keep thinking about it. If the Debian NSS maintainer has a strong opinion to remove CAcert's roots, then the same will happen in ca-certificates, in order to maintain the same CA set. I just personally have no strong opinion either way - I think it's great that Debian supports such a project, and I think it would be a shame to remove that support. I think every CA probably has it's warts, but the CA system is what we have, good or bad. Kind regards, Michael

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 00:24:04 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 00:24:04 GMT) (full text, mbox, link).

Message #87 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Michael Shuler <michael@pbandjelly.org>, 731463@bugs.debian.org, 718434@bugs.debian.org Subject: Re: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 06 Dec 2013 19:21:52 -0500

On 12/06/2013 07:13 PM, Michael Shuler wrote: > #2 - All CAs included in ca-certificates are available to have the trust > turned off. If you have a concern about a particular CA and do not > trust them, disable that CA. can we ship CAs marked as "disabled" by default? my impression is that every CA shipped in ca-certificates right now is enabled automatically unless the user has debconf's priority set to be more verbose than the default. > I'll keep thinking about it. If the Debian NSS maintainer has a strong > opinion to remove CAcert's roots, then the same will happen in > ca-certificates, in order to maintain the same CA set. The other way to maintain the same CA set is for Someone™ to fix #704180 --dkg

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 01:15:10 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Sat, 07 Dec 2013 01:15:10 GMT) (full text, mbox, link).

Message #92 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 718434@bugs.debian.org, 731463@bugs.debian.org Subject: Re: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 06 Dec 2013 19:11:19 -0600

On 12/06/2013 06:21 PM, Daniel Kahn Gillmor wrote: > can we ship CAs marked as "disabled" by default? I think this would prove to be a rather severe disservice to Debian users, making all SSL connections fail for all software that is or depends on one of the reverse dependencies of ca-certificates. Kind regards, Michael

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 02:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 02:21:04 GMT) (full text, mbox, link).

Message #97 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Michael Shuler <michael@pbandjelly.org>, 731463@bugs.debian.org, 718434@bugs.debian.org Subject: Re: Bug#731463: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 06 Dec 2013 21:18:28 -0500

On 12/06/2013 08:11 PM, Michael Shuler wrote: > On 12/06/2013 06:21 PM, Daniel Kahn Gillmor wrote: >> can we ship CAs marked as "disabled" by default? > > I think this would prove to be a rather severe disservice to Debian > users, making all SSL connections fail for all software that is or > depends on one of the reverse dependencies of ca-certificates. I didn't mean to imply that we would ship all CAs as disabled by default -- i agree that would probably be unhelpful. i just meant that the decision about "not including CAcert.org" doesn't need to be a binary decision -- instead of dropping it, we could ship the certificate, but have it disabled by default, while leaving the others alone. --dkg

Information forwarded to debian-bugs-dist@lists.debian.org :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 03:18:04 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Shuler <michael@pbandjelly.org> :

Extra info received and forwarded to list. (Sat, 07 Dec 2013 03:18:04 GMT) (full text, mbox, link).

Message #102 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 718434@bugs.debian.org, 731463@bugs.debian.org Subject: Re: Bug#718434: Bug#731463: ca-certificates: should CAcert.org be included? Date: Fri, 06 Dec 2013 21:15:29 -0600

On 12/06/2013 08:18 PM, Daniel Kahn Gillmor wrote: > On 12/06/2013 08:11 PM, Michael Shuler wrote: >> On 12/06/2013 06:21 PM, Daniel Kahn Gillmor wrote: >>> can we ship CAs marked as "disabled" by default? >> >> I think this would prove to be a rather severe disservice to Debian >> users, making all SSL connections fail for all software that is or >> depends on one of the reverse dependencies of ca-certificates. > > I didn't mean to imply that we would ship all CAs as disabled by default > -- i agree that would probably be unhelpful. i just meant that the > decision about "not including CAcert.org" doesn't need to be a binary > decision -- instead of dropping it, we could ship the certificate, but > have it disabled by default, while leaving the others alone. Thanks for the clarification, I misunderstood. This would be possible, but it makes for an interesting question of toggling other CAs, which I don't care to take on, since it seems to be a rather polar and emotional conversation. It it already simple to drop in a local certificate, as well as create a local cert deb package. In my opinion, the question really is binary - we either ship it and trust it, or we don't. -- Kind regards, Michael

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 06:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 06:27:04 GMT) (full text, mbox, link).

Message #107 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Michael Shuler <michael@pbandjelly.org>, 731463@bugs.debian.org, 718434@bugs.debian.org Subject: Re: Bug#731463: Bug#718434: Bug#731463: ca-certificates: should CAcert.org be included? Date: Sat, 07 Dec 2013 01:24:31 -0500

On 12/06/2013 10:15 PM, Michael Shuler wrote: > Thanks for the clarification, I misunderstood. This would be possible, > but it makes for an interesting question of toggling other CAs, which I > don't care to take on, since it seems to be a rather polar and emotional > conversation. Deciding to eject CAs *also* raises the question of ejecting other CAs. I don't think we can get around the fact that this is a difficult decision to make, and no one actually wants to be in the position of making it. But if debian is shipping a bundle of CAs, we are actually making that decision; even if we punt the details of the decision to "major browser vendor(s)", we're deciding which vendor(s) to defer to. As an OS distributor, we are forced to make these decisions (or at least the defaults) for our users because of structural flaws in the global environment that enables the CA cartel. Saying "hey, it's up to mozilla" and washing our hands of the matter doesn't seem particularly > It it already simple to drop in a local certificate, as > well as create a local cert deb package. In my opinion, the question > really is binary - we either ship it and trust it, or we don't. Having the certificate shipped in the debian package but disabled by default is still useful: it provides an easy and standard way for administrators who are willing to rely on CAcert to know that they have the expected certificate, rather than having to fetch the CACert package via some potentially unreliable channel. Thanks for thinking about this problem for debian and its users. --dkg

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 11:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Alessandro Vesely <vesely@tana.it> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 11:27:04 GMT) (full text, mbox, link).

Message #112 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Alessandro Vesely <vesely@tana.it> To: Geoffrey Thomas <geofft@ldpreload.com> Cc: 718434@bugs.debian.org Subject: Re: Bug #718434, please leave CAcert as is Date: Sat, 07 Dec 2013 12:23:45 +0100

On Thu 05/Dec/2013 20:16:57 +0100 Geoffrey Thomas wrote: > > Can you quantify what you mean by "useful" and "handy"? It is just convenient. Using curl, for example, you can skip some prior settings and command line options. > If there are use cases for CAcert other than the fact that their > certificates are free-of-charge, I'd be curious to know that, but I'm > under the impression that that's basically the only driver these days, > and my arguments in this thread are mostly based on that. It seems to me CAcert certificates are free, not free-of-charge. The difference is between "free beer" and "free speech", as they say. I see that other providers offer free-of-charge certificates, and I consider those marketing strategies ultimately aimed at improving their sales. >> From a practical POV, the incidents reported by THC[0] mention >> different CAs, so I'd rather remove them than CAcert. > > I believe all those roots were either removed from the Mozilla set, or > rekeyed. A THC reported line says "Comodo (InfoSecurity, 2011). Not once, but multiple times." Yet, on wheezy, I have: for f in /usr/share/ca-certificates/mozilla/Comodo*; \ do certtool -i --infile $f | grep 'Not Before'; done Not Before: Thu Jan 01 00:00:00 UTC 2004 Not Before: Thu Jan 01 00:00:00 UTC 2004 Not Before: Thu Jan 01 00:00:00 UTC 2004 That doesn't hurt me. IMHO, it is beyond Debian responsibilities to independently investigate on security incidents. When an upstream maintainer/provider identifies a security weakness and issues a patch, the Debian security team follows up, and I think that's enough. > For what it's worth, I'd be happy to see Debian be _more_ > conservative than Mozilla in what roots it includes, just not less. I beg to differ. In order to be conservative, Debian should devise objective criteria for auditing and assessing each CA. Carrying that activity out would consume an amount of resources, while the added value would be minimal: Server admins have to choose the CAs that better suit their needs anyway, regardless of Debian mumblings. So, including any known CA (unless it is a blatant scam, of course) seems to be a more effective approach. >> If anything, it should made clear[er] that there is no endorsement >> or assumption of responsibility in distributing ca-certificates: >> Just like any other package, it is done on a best-effort basis. > > I actually do think that's the right policy for Debian, but in the > form that Debian should pass the trust questions off to an entity like > Mozilla who is willing to make those endorsements (since the only > other real way to make "no endorsement" clear is to make no roots > trusted by default). Mozilla can make rather strict assumptions on how the certificates they accept are going to be used. Debian used to be more generic, and I don't think this post-disclosure period is the best moment to introduce policy restrictions. If it works, don't fix it; use it.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 12:57:04 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 12:57:04 GMT) (full text, mbox, link).

Message #117 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: Daniel Kahn Gillmor <dkg@fifthhorseman.net> Cc: 731463@bugs.debian.org, 718434@bugs.debian.org Subject: Re: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sat, 7 Dec 2013 13:54:37 +0100

Hi Daniel, On Saturday 07 December 2013 01:21:52 Daniel Kahn Gillmor wrote: > can we ship CAs marked as "disabled" by default? my impression is that > every CA shipped in ca-certificates right now is enabled automatically > unless the user has debconf's priority set to be more verbose than the > default. I'm personally inclined to do something along those lines for CAcert as a way to discontinue it. > The other way to maintain the same CA set is for Someone™ to fix #704180 While I like that solution (having to modify nss to add/remove certs is a PITA), I wonder how trust settings should be managed. With nss' ckbi store you can ship a certificate and indicate no trust setting for a specific use, distrust, etc. No trust setting can be determined from /etc/ssl/certs, losing important information. Do you know if there's already a plan to address that shortcoming? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Sat, 07 Dec 2013 13:48:07 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Sat, 07 Dec 2013 13:48:08 GMT) (full text, mbox, link).

Message #122 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Raphael Geissert <geissert@debian.org> Cc: 731463@bugs.debian.org, 718434@bugs.debian.org, 704180@bugs.debian.org Subject: Re: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included? Date: Sat, 07 Dec 2013 08:44:56 -0500

On 12/07/2013 07:54 AM, Raphael Geissert wrote: > On Saturday 07 December 2013 01:21:52 Daniel Kahn Gillmor wrote: >> The other way to maintain the same CA set is for Someone™ to fix #704180 > > While I like that solution (having to modify nss to add/remove certs is a > PITA), I wonder how trust settings should be managed. With nss' ckbi store > you can ship a certificate and indicate no trust setting for a specific use, > distrust, etc. No trust setting can be determined from /etc/ssl/certs, > losing important information. > Do you know if there's already a plan to address that shortcoming? (setting followup-to: #704180 for this sub-thread) my understanding of ca-certificates is that /etc/ssl/certs is itself a (coarse-grained) trust setting. That is, we have a bunch of certs shipped in /usr/share/ca-certificates, and during the ca-certificates.postinst maintainer script, those certificates selected as "trusted" by the system administrator are symlinked from /etc/ssl/certs. By default, if the admin has low debconf priority: all of them are considered trusted. This isn't the finer-grained trust available in the traditional nssckbi, which lets you break out three different broad areas of reliance: * certify web servers * certify e-mail users * certify code signatures so ca-certificates and /etc/ssl/certs is slightly more clunky. But frankly, even nss-ckbi is clunky by comparison with what anyone who cares about this would sensibly want. For example, i might only want to rely on the CA from example.com's administrators to be able to certify e-mail users *within example.com*. p11-kit has proposed mechanisms (i haven't tested them, but as i understand it, the idea is to associate extra X.509v3 extensions with the certificates in question) to implement this sort of finer-grained permission, even if it is not represented by ca-certificates. So it seems sensible to me to start with the coarse-grained nssckbi override using ca-certificates' coarse "all-or-nothing" approach to demonstrate basic functionality, and then figure out how to adjust the finer-grained nuance within p11-kit itself. --dkg

Added tag(s) pending. Request was from Michael Shuler <michael@pbandjelly.org> to control@bugs.debian.org . (Sun, 23 Feb 2014 22:00:08 GMT) (full text, mbox, link).

Reply sent to Michael Shuler <michael@pbandjelly.org> :

You have taken responsibility. (Thu, 13 Mar 2014 13:06:13 GMT) (full text, mbox, link).

Notification sent to Ansgar Burchardt <ansgar@debian.org> :

Bug acknowledged by developer. (Thu, 13 Mar 2014 13:06:13 GMT) (full text, mbox, link).

Message #129 received at 718434-close@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org> To: 718434-close@bugs.debian.org Subject: Bug#718434: fixed in ca-certificates 20140223 Date: Thu, 13 Mar 2014 13:03:23 +0000

Source: ca-certificates Source-Version: 20140223 We believe that the bug you reported is fixed in the latest version of ca-certificates, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 718434@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Michael Shuler <michael@pbandjelly.org> (supplier of updated ca-certificates package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Sun, 23 Feb 2014 23:22:29 -0600 Source: ca-certificates Binary: ca-certificates Architecture: source all Version: 20140223 Distribution: unstable Urgency: medium Maintainer: Michael Shuler <michael@pbandjelly.org> Changed-By: Michael Shuler <michael@pbandjelly.org> Description: ca-certificates - Common CA certificates Closes: 635570 683403 718434 727136 Changes: ca-certificates (20140223) unstable; urgency=medium . * No longer ship cacert.org certificates. Closes: #718434, LP: #1258286 * Fix certdata2pem.py for multiple CAs using the same CKA_LABEL. Thanks to Marc Deslauriers for the patch. Closes: #683403, LP: #1031333 * Sort local CA certificates on update-ca-certificates runs. Thanks to Vaclav Ovsik for the suggestion and patch. Closes: #727136 * Add trailing newline to certificate, if it is missing. Closes: #635570 * Update mozilla/certdata.txt to version 1.97. Certificates added (+), removed (-), and renamed (~): + "ACCVRAIZ1" + "Atos TrustedRoot 2011" + "E-Tugra Certification Authority" + "SG TRUST SERVICES RACINE" + "T-TeleSec GlobalRoot Class 2" + "TWCA Global Root CA" + "TeliaSonera Root CA v1" + "Verisign Class 3 Public Primary Certification Authority" ~ "Verisign Class 3 Public Primary Certification Authority"_2 (both Verisign Class 3 CAs now included with duplicate CKA_LABEL fix) - "Entrust.net Secure Server CA" - "Firmaprofesional Root CA" - "GTE CyberTrust Global Root" - "RSA Root Certificate 1" - "TDC OCES Root CA" - "ValiCert Class 1 VA" - "ValiCert Class 2 VA" - "Wells Fargo Root CA" Checksums-Sha1: 5c16595be2d53faae390f91d8e46b292f100b2b8 1420 ca-certificates_20140223.dsc ad57a45f0422fafd78a2e8191e5204f2306cc91b 274768 ca-certificates_20140223.tar.xz be6a0d32c76ae4adaafc04aefb56bb00b5cc72ed 190226 ca-certificates_20140223_all.deb Checksums-Sha256: d3be3f9ecba77f7feb176cbc1fb1df2ad320b29368b53a3d9d9f70a0713d5ce3 1420 ca-certificates_20140223.dsc 815b7cd97200b0d76450bb3e7d9b65997ac494ab6467b17369f65b2ef94bcb0c 274768 ca-certificates_20140223.tar.xz 13cb11144a97d95a8be130e4bcdd6c9ffc3df269bb194699bcd21ca377e01df2 190226 ca-certificates_20140223_all.deb Files: fcf461554a554420e0359d7810269cc0 1420 misc optional ca-certificates_20140223.dsc ff4049c32342ea450cda82bb14026ffd 274768 misc optional ca-certificates_20140223.tar.xz 555a2965e08517f0ef84a8810016f75b 190226 misc optional ca-certificates_20140223_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTIap0AAoJEFb2GnlAHawE+kAH/1QGWMJV89sAmclrYeeyDKvl 9PnaATmhoVow3yL+Qg/CBKUZeahlXrBdQt7QsItn6whH2NOQUiWbsprzImZdT3xo GOHSWRBbjosmz1Uco1Iw2abdUIfPDnWvQEEo5oHnHg38s/3wcI/ADDTXkuf69PNT joGdyBYsJyAH/ltw6WiwiKO0nYwAQv006d/Q9jn8rqOB0MIwx4EUR+Z/qtZRk++n Xob/g6EsoqbKgB0MH4kqnhn1ZSKBQviTZOlhfkoe2KWfJZCpOmTmDYXdZb7Kh3TC 2nw+FC9ees/ccdwDrnGnif+Mp3CPGrXjbvDvH1kX04nFrP0fI86ClnNlE1VAnoQ= =VLPi -----END PGP SIGNATURE-----

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 16:30:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 16:30:04 GMT) (full text, mbox, link).

Message #134 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net> To: 718434@bugs.debian.org Cc: 718434-subscribe@bugs.debian.org Subject: Re: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 17:21:08 +0100

I doubt that the removal of CAcert was a good decision... We include such doubtful CAs as CNNIC, TURKTRUST, and all the (ultimately) NSA controlled US-based CAs... so whether the audit of CAcert looks promising now or not does not really matter that much, if you compare it to the others. And we just include the others because Mozilla does so, and Mozilla itself is highly criticised in many bugs by security experts for some of their choices. Actually, Mozilla seems to include everything, as soon as the CA fulfils some basic rules (which however no one really verifies) - and even if comes out that a CA was untrustworthy and broke the rules, they don't remove them but rather just believe in good faith that in the future everything will change... o.O And many of the other commercial CAs have proven dozens of times that they are neither trustworthy, nor particular competent. And as for the license... First it's questionable whether a certificate is licensable at all (I mean it's just some numbers)... and even if... then what about the other certs that we got from mozilla? Do we really know whether all these certs are DFSG compatible? So I don't quite see the use of removing the CAcert.org certificates (actually I wonder why we have ca-certificates at all, since it seems to be merely the Mozilla CA package)... since it was for most Debian users the only way to get them in a secure manner. Cheers, Chris.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 22:12:04 GMT) (full text, mbox, link).

Acknowledgement sent to Axel Beckert <abe@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 22:12:04 GMT) (full text, mbox, link).

Message #139 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org> To: Christoph Anton Mitterer <calestyo@scientia.net>, 718434@bugs.debian.org Cc: Yeah I subscribe too <718434-subscribe@bugs.debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 23:09:48 +0100

Hi, Christoph Anton Mitterer wrote: > I doubt that the removal of CAcert was a good decision... A quite bad decision in my view, too. Already having CAcert root certificiates in the right place over really trusted ways (secure apt) is^Wwas one of Debian's cooler features. So thanks Chris for his elaborate reasoning, showing why the removal is a bad idea. With the exception that you think that ca-certificates is merely the Mozilla CA package, I do agree with Chris' reasoning. The administrator of a machine can easily disable certificiates he doesn't trust, but only if they are included in ca-certificates. So if it helps including CAcert's root certificates again in ca-certificates, please include them, but disable them by default if they're not up to some (IMHO questionable) inclusion policy. That way, every user can securely download them via APT and enable them for the whole system (and not only per browser) if wanted. I really hope that the ca-certificates maintainers come back to their senses again and revert this unsound removal soon. Regards, Axel -- ,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 22:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 22:21:04 GMT) (full text, mbox, link).

Message #144 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Axel Beckert <abe@debian.org>, 718434@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net> Cc: Yeah I subscribe too <718434-subscribe@bugs.debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 18:15:49 -0400

On 03/13/2014 06:09 PM, Axel Beckert wrote: > The administrator of a machine can easily disable certificiates he > doesn't trust, but only if they are included in ca-certificates. > > So if it helps including CAcert's root certificates again in > ca-certificates, please include them, but disable them by default if > they're not up to some (IMHO questionable) inclusion policy. That way, > every user can securely download them via APT and enable them for the > whole system (and not only per browser) if wanted. I agree with Axel's suggestion here. --dkg

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 22:21:08 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 22:21:08 GMT) (full text, mbox, link).

Message #149 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: Axel Beckert <abe@debian.org>, 718434@bugs.debian.org Cc: Christoph Anton Mitterer <calestyo@scientia.net> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 23:17:50 +0100

Hi, On Thursday 13 March 2014 23:09:48 Axel Beckert wrote: > Christoph Anton Mitterer wrote: > > I doubt that the removal of CAcert was a good decision... > > A quite bad decision in my view, too. Thanks for sharing your thoughts. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 22:48:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 22:48:04 GMT) (full text, mbox, link).

Message #154 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net> To: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 23:44:13 +0100

On Thu, 2014-03-13 at 23:09 +0100, Axel Beckert wrote: > With the exception that you think that ca-certificates > is merely the Mozilla CA package Well of course I know that the Mozilla/NSS packages (iceweasel, etc.pp.) do actually not even use ca-certificates... but looking at it, the only additional root cert seems to be the one from SPI. > The administrator of a machine can easily disable certificiates he > doesn't trust IMHO it should be vice versa... ca-certificates should activate _no_ certs per default... and only the admin should choose which he trusts; a task which neither we, nor Mozilla can reliably do for anyone (actually this is the inherent problem of strict hierarchical trust models and and why X509 is inherently broken). I'd rather see ca-certificates as a collection of root certs, for which it is assured that they are what they claim to be (respectively blong to which they claim).... E.g. that a Verisign<something> cert is really one from Verisign... and that a CERN Root CA,... is really the one from CERN. There should be no (implied) statement at all about whether these root certs fulfil any particular policy (like WebTrust) or anything else. Cheers, Chris.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Thu, 13 Mar 2014 22:54:04 GMT) (full text, mbox, link).

Acknowledgement sent to Axel Beckert <abe@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Thu, 13 Mar 2014 22:54:04 GMT) (full text, mbox, link).

Message #159 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org> To: Christoph Anton Mitterer <calestyo@scientia.net>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Thu, 13 Mar 2014 23:51:43 +0100

Hi Chris, Christoph Anton Mitterer wrote: > On Thu, 2014-03-13 at 23:09 +0100, Axel Beckert wrote: > > With the exception that you think that ca-certificates > > is merely the Mozilla CA package > Well of course I know that the Mozilla/NSS packages (iceweasel, etc.pp.) > do actually not even use ca-certificates... but looking at it, the only > additional root cert seems to be the one from SPI. The latter was my point, yes. > > The administrator of a machine can easily disable certificiates he > > doesn't trust > IMHO it should be vice versa... ca-certificates should activate _no_ > certs per default... You've got a point there! > and only the admin should choose which he trusts; a task which > neither we, nor Mozilla can reliably do for anyone (actually this is > the inherent problem of strict hierarchical trust models and and why > X509 is inherently broken). *nod* > I'd rather see ca-certificates as a collection of root certs, for which > it is assured that they are what they claim to be (respectively blong to > which they claim).... > E.g. that a Verisign<something> cert is really one from Verisign... and > that a CERN Root CA,... is really the one from CERN. > > There should be no (implied) statement at all about whether these root > certs fulfil any particular policy (like WebTrust) or anything else. I like that idea. :-) Regards, Axel -- ,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 05:33:04 GMT) (full text, mbox, link).

Acknowledgement sent to "Thomas R. Koll" <tomk32@gmail.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 05:33:04 GMT) (full text, mbox, link).

Message #164 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thomas R. Koll" <tomk32@gmail.com> To: Christoph Anton Mitterer <calestyo@scientia.net>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 06:31:48 +0100

Am 13.03.2014 um 17:21 schrieb Christoph Anton Mitterer <calestyo@scientia.net>: > I doubt that the removal of CAcert was a good decision… I wish you would have read the whole the bug report, especially the history of how the CACert root certificate came into ca-certificates. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#20 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#30 In a nutshell, if you want CACert to be re-added you must prove CACert and its infrastructure is trustworthy. Something CACert has attempted but even their internal audits have failed. ca-certificates didn’t have much of a policy until recently, but giving that a good, secure policy can take quite some work, relying on Mozilla is a sensible policy. Plus that SPI root cert, but they run debian infrastructure. Please do not reason against the removal, instead you have to prove (every year in my eyes) that CACert is trustworthy. Inverting the burden of proof, as it has happended far to often in these CACert discussions, is unacceptable when talking about security. A small question to be added and a few people supporting the request just won’t pull any longer. Please stop dragging other CAs around for comparison, every CA has to prove trustworthiness on their own. ciao, tom PS: Lastly, this is not an opinion poll. If your only contrib is a +/-1, close your mail programm.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 06:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 06:09:04 GMT) (full text, mbox, link).

Message #169 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: "Thomas R. Koll" <tomk32@gmail.com>, 718434@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net> Cc: Axel Beckert <abe@debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 02:07:07 -0400

Hi Thomas-- Thanks for the time and consideration you've put into this discussion, and for your clarifying remarks. On 03/14/2014 01:31 AM, Thomas R. Koll wrote: > In a nutshell, if you want CACert to be re-added you must prove > CACert and its infrastructure is trustworthy. > Something CACert has attempted but even their internal audits have failed. I don't think the argument is quite as clear-cut. we don't even need audits to know that groups like verisign and rapidssl have failed to avoid mis-issuing certs, and yet we keep them in the ca-certificates package because of the perverse incentives created by the CA ecosystem. some of these CAs are simply "too big to fail" right now; CACert is not, so they're getting called out for their lack of security, whereas we simply can't afford to drop the other CAs because users would complain about not being able to reach their favorite web sites :( This tension results in further concentration of business among the "too big to fail" CAs (since they're the only ones who can issue acceptable certs, which ironically results in them being even less accountable to relying parties in the future. This is not a good long-term dynamic. > ca-certificates didn’t have much of a policy until recently, but giving that > a good, secure policy can take quite some work, relying on Mozilla > is a sensible policy. Plus that SPI root cert, but they run debian infrastructure. This is not a good argument for including the SPI root cert, frankly. Running debian infrastructure does mean that you can compromise my machine by pushing out malicious software updates. but if i decide to stop accepting software updates, or switch to some other set of apt repositories, i'm protected against that channel going forward. Also, it's possible for me to verify that the software updates i'm seeing are the same as the software updates that other people on the 'net are seeing (most cheaply, i can approximate this by regularly varying my choice of apt mirror); this makes an attack on me via software updates much more easily detectable, and makes it more difficult for someone in charge of debian infrastructure to target me directly. With SPI's root cert, stopping software updates or varying my choice of debian mirror does *not* defend me against malicious use of the CA, and an attack can be much more narrowly tailored and hard to detect. Really, this is a lot of pressure on the operators of the SPI CA, and we have very little oversight on its practice. I like and respect the operators of the SPI CA, but this is not a responsibility i would necessarily want to have on my own shoulders; if i was in their position, i would actively prefer that the infrastructure i manage be publicly monitored so that other people could alert me (and other relying parties) if it gets broken. at the moment, i don't think such monitoring exists. > Please do not reason against the removal, instead you have to > prove (every year in my eyes) that CACert is trustworthy. > Inverting the burden of proof, as it has happended far to often > in these CACert discussions, is unacceptable when talking about security. > A small question to be added and a few people supporting the > request just won’t pull any longer. > > Please stop dragging other CAs around for comparison, every CA has to > prove trustworthiness on their own. except for the ones that we rely on mozilla for, and mozilla themselves are forced to carry the "too big to fail" CAs or else users will switch to Chrome or IE. > PS: Lastly, this is not an opinion poll. If your only contrib is a +/-1, > close your mail programm. This last remark seems unnecessarily rude. One of the ways that the CA ecosystem develops (and that debian knows what to care about) is by people being vocal about what they want and who they are willing to rely on. This is how the large CAs stay in their position currently -- people complain if we turn them off because they can't get to their favorite web sites. Why should we deny that particular channel of recourse to the folks who prefer to rely on community organizations? If someone agrees with a point that they think isn't being listened to, then indicating agreement is a valuable contribution. Axel, it occurs to me that one thing the CACert folks could do is to ship a new package in debian that Depends: (and maybe Enhances:) ca-certificates, which just ships the CACert root cert in the common and runs the appropriate scripts in postinst; that would be roughly equivalent to "off by default" and would still provide the cryptographically-strong channel to fetch the CACert root cert itself. Regards, --dkg

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 08:48:05 GMT) (full text, mbox, link).

Acknowledgement sent to Axel Beckert <abe@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 08:48:05 GMT) (full text, mbox, link).

Message #174 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org> To: "Thomas R. Koll" <tomk32@gmail.com>, 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 09:44:36 +0100

Hi Thomas, Thomas R. Koll wrote: > In a nutshell, if you want CACert to be re-added you must prove > CACert and its infrastructure is trustworthy. That's IMHO the wrong check for inclusion. As I already wrote in my initial mail (you should have read it fully... ;-), I suggest to include but disable it by default since I do see the issues. See Christoph's and Daniel's mails for reasoning details. > Please do not reason against the removal, instead you have to > prove (every year in my eyes) that CACert is trustworthy. Feel free to disable any certificate by default you don't think it's trustworthy. Disable all if you want. I'm fine with it. But if you're assure that it's source is authentic, then include it. As Christoph suggested, ca-certificates should rather focus on authenticity than on trustworthyness. Because trust is something which is missing a lot in the current global SSL infrastructure, independent of how much audits are there or not. > PS: Lastly, this is not an opinion poll. It obviously is if you look at the heated discussion. The only thing I miss in the Debian BTS compared to Launchpad is that I can't easily say "I'm affected by this issue to" aka the "me too" button. I think that's a great way to show the maintainer what really matters to the mass of users without getting tons of e-mails because of that. If an issue is really annoying, you even get "me toos" by e-mail in the Debian BTS because of the missing button. I'd expect you would have gotten quite some of these "me too" clicks in #741561. Regards, Axel -- ,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 09:03:04 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 09:03:04 GMT) (full text, mbox, link).

Message #179 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org> To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 718434@bugs.debian.org Cc: "Thomas R. Koll" <tomk32@gmail.com>, Christoph Anton Mitterer <calestyo@scientia.net>, Axel Beckert <abe@debian.org> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 09:59:08 +0100

Hi Daniel, On 14 March 2014 07:07, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > On 03/14/2014 01:31 AM, Thomas R. Koll wrote: [your thoughts on the CA ecosystem] Thanks for sharing your opinion. >> ca-certificates didn’t have much of a policy until recently, but giving that >> a good, secure policy can take quite some work, relying on Mozilla >> is a sensible policy. Plus that SPI root cert, but they run debian infrastructure. > > This is not a good argument for including the SPI root cert, frankly. [...] We are closely watching the transition from SPI certificates to the ones provided by Gandi. Once the transition is finished we are very likely going to also drop the SPI root certificate. P.S. as a gentle reminder, a decision has been made by the maintainers. The result can be found in the archive. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 09:57:04 GMT) (full text, mbox, link).

Acknowledgement sent to Klaus Ethgen <Klaus@Ethgen.ch> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 09:57:04 GMT) (full text, mbox, link).

Message #184 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Klaus Ethgen <Klaus@Ethgen.ch> To: "Thomas R. Koll" <tomk32@gmail.com>, 718434@bugs.debian.org Cc: Christoph Anton Mitterer <calestyo@scientia.net> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 10:54:36 +0100

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Fr den 14. Mär 2014 um 6:31 schrieb Thomas R. Koll: > Am 13.03.2014 um 17:21 schrieb Christoph Anton Mitterer <calestyo@scientia.net>: > > I doubt that the removal of CAcert was a good decision? > > I wish you would have read the whole the bug report, especially the history > of how the CACert root certificate came into ca-certificates. I believe, he did as I and many more too. Hovever, I cannot prove for him. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#20 and > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#30 > > In a nutshell, if you want CACert to be re-added you must prove > CACert and its infrastructure is trustworthy. > Something CACert has attempted but even their internal audits have failed. Well, CAcert is not more or less trustworth as every other CA in the package. In fact, I would trust them much more that such suspect CAs as TURKTRUST or Verisign. The certificate was in this package for long time and was a proper source for the admin to enable it or not. Now it is gone and this is breaking many work flows. If you want to only include trustworth CAs in the package, then you might better do a rm -fr *. I do believe that no one in debian is able to validate every single CA. It is not a point to readd a certificate than to revert to the unbroken state before. > Please do not reason against the removal, instead you have to > prove (every year in my eyes) that CACert is trustworthy. Sure, as soon as you prove that TURKTRUST is trustworthy or Verisign or Wells_Fargo or China_Internet_Network_Information_Center (Just to name few). On the other hand, for example Verisign had some bad news records in the last years. (I do not have a link anymore) > Please stop dragging other CAs around for comparison, every CA has to > prove trustworthiness on their own. No, I for myself will never stop with that until you show that you set the same measurement for all certs. I do not think that any of the CAs was checked for trustworthiness before including them in ca-certificates. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@Ethgen.de> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJTItHaAAoJEKZ8CrGAGfas/tsL/iXjwBjsuxcXxI6QXrcpaDTZ vYuTfQSOk4tjJEslMiTHw7+Hnikm8Vxhbnk9e/eq4Il54ua24lNFbytOUGrUY1kS jeuPGfTO0BpBVtauUgpOGMVAOOAMOWmogCNW8K9ov2IIlK5q69Z4kbjof/9YZSn3 tCov205ukXIlaZkNrg15Xh76qR8VcvGqgfFwzAujjDCVgo4R3fT+8rczcE0k7LUP YdHzP9mXN7Jl2X4UGABL2SUUmQGQaeIY2JOT8DMSEk1++3l8PkkPyRzGmBn8ldkj WRLQhyvINCStlBnzmyBsUSXTavei5uiaLHeUgFs8MoLg4qu/OQOmZuegbMIPJ+gp ccSqt4DSKoETEDFnzuMTcNsxyiprTS5Qnd83E9i9dsKlcwMAr0VkIcuxQcZJKt0I jw7Wzks9Ukjmq9rdWIw21AqbpWbiXcxqqUZ20P8bldqKgT6+1qPIZ76s2NNhBOAA fvfdJOrHdyX20iuTo9BOps72T5JXfKrRODmTEBnxAQ== =BeXK -----END PGP SIGNATURE-----

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 10:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to "Thomas R. Koll" <tomk32@gmail.com> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 10:27:05 GMT) (full text, mbox, link).

Message #189 received at 718434@bugs.debian.org (full text, mbox, reply):

From: "Thomas R. Koll" <tomk32@gmail.com> To: Klaus Ethgen <Klaus@Ethgen.ch> Cc: 718434@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net> Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 11:22:12 +0100

Am 14.03.2014 um 10:54 schrieb Klaus Ethgen <Klaus@Ethgen.ch>: > > In a nutshell, if you want CACert to be re-added you must prove > > CACert and its infrastructure is trustworthy. > > Something CACert has attempted but even their internal audits have failed. > > Well, CAcert is not more or less trustworth as every other CA in the > package. In fact, I would trust them much more that such suspect CAs as > TURKTRUST or Verisign. Those certificates packaged by and copied over from Mozilla do fullfil their policy which can be found here: http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ In the inclusion section your can find a lot of ways to get accepted by Mozilla, but CACert has failed to fullfil any of those. And to quote from their policy: "The burden is on the CA to prove that it has met the above requirements.“ But who knows, with CACert’s move from Australia to Germany we could see some more action behind the efforts for an audit. Personally I don’t have the CACert root certificate in my trusted certs folder, instead for every website and service that uses a CACert certificate I check and accept that cert. ciao, tom

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 22:24:16 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 22:24:16 GMT) (full text, mbox, link).

Message #194 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net> To: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 23:20:19 +0100

On Fri, 2014-03-14 at 06:31 +0100, Thomas R. Koll wrote: > In a nutshell, if you want CACert to be re-added you must prove > CACert and its infrastructure is trustworthy. > Something CACert has attempted but even their internal audits have failed. Well but to be honest... that is plain stupid and makes it somehow questionable whether you understand the stuff and especially problems behind X.509. You will never be able to guarantee trustworthiness of any of these certs for Debian's users. Full stop. And countless examples of other commercial CAs proved this. Diginotar, Digicert, Turktrust, etc. They all were in the Mozilla bundle,.. they all passed their audits, they all failed miserable... and these are just the tip of the ice rock we know about. You can be a 100% sure, that CNNIC and US controlled CAs are used by their respective governments for attack... and even if those CAs would not want that, they would have to,... e.g. when being forced by national security letters in the US... they couldn't even tell the public what they were doing due to the gag order. > ca-certificates didn’t have much of a policy until recently, but giving that > a good, secure policy can take quite some work, relying on Mozilla > is a sensible policy. Well but the Mozilla policy is worthless and actually Mozilla proved several times now, that they deliberately include CAs which are proven to be not trustworthy. > Plus that SPI root cert, but they run debian infrastructure. And if you really go by the argument, that only trustworthy CAs should be included, that was the _only_ one which I'd agree to be worth to include. > Please do not reason against the removal, instead you have to > prove (every year in my eyes) that CACert is trustworthy. I do not argue against the removal, I rather argue against the general policy, since I think it makes no sense. Does any of the CAs in the Mozilla bundle prove you to be trustworthy? Or is it just because Mozilla added them (probably for money reasons)? And what do you think about cases like e.g. turktrust, where it was known that they forge certificates, but Mozilla still decided to keep them, because they promised never to do again (which actually they did in the first place as well, when they've "passed" the audit)? Apart from that: How would one convince you? I mean below you said the effort of checking trustworthiness shouldn't be upon you (which is fine),... but even if there was some "proper" audit... it would be actually on you, since you'd have to check those documents. Or is trustworthiness defined by the CA being based in a "good" country, like Iceland? Or is it based on customers being required to pay money in order to get a cert? You see, all this is just the reason of why your approach to include "trustworthy" certs is wrong... just because the model of X.509 is broken,... I mean this is known for years by experts but only got attention in the recent years, when many examples proved how useless the hole system is. And as a matter of fact,.. the more CAs you include, the more useless it gets. And even things like EV certs don't really help, but just move the problem to the next level. Now you say you intent do only include trustworthy CAs, right? And thereby you kinda promise Debian users of the package... when you use trust certs from that you'll be fine. Failed. You include CNNIC (and more) => not trustworthy > Inverting the burden of proof, as it has happended far to often > in these CACert discussions, is unacceptable when talking about security. Well apparently you can't talk about security, ... if at all you talk about trustworthiness, but even that you can't guarantee... you rather just rely it on the good faith of Mozilla, which proves over and over again to fail in that area. > Please stop dragging other CAs around for comparison, every CA has to > prove trustworthiness on their own. Then the request should probably be to remove all the mozilla/* certs as well from the package, since those are similarly untrustworthy,... starting by all US-based CAs (due to them being ultimately controlled by the NSA, via national security letters) the Chinese based and those CAs which are known to have issued forged certificates for reasons of making money. > PS: Lastly, this is not an opinion poll. If your only contrib is a +/-1, > close your mail programm. Well obviously a maintainer is free to do what he wants (at least until the tech-ctte tells different),.. but this doesn't mean that he can forbid people to tell what they think. And as said,... right now ca-certificates is in a pretty useless state... it's merely another re-bundling of the mozilla certs + SPI,... and as long as it is like that, it would probably be better (and more up-to-date) to simply have a wrapper, that extracts the certs from the current NSS packages. I mean it's nice and appreciated that you spend effort on ca-certificates which was in a sleeping state for quite a while,... but you're approaching to it all the wrong way. And don't get me wrong,... it's not that I would consider CAcert particularly trustworthy, since 3 people can already forge any identity. But that's not worse than any of the commercial CAs where you can get the same for some 20-50$. Cheers, Chris.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 22:30:05 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 22:30:05 GMT) (full text, mbox, link).

Message #199 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net> To: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 23:26:30 +0100

On Fri, 2014-03-14 at 09:59 +0100, Raphael Geissert wrote: > We are closely watching the transition from SPI certificates to the > ones provided by Gandi. Which btw is another really bad idea... Debian should have it's own CA (if X.509 is used in places to secure it's services)... and that CA should also be used to secure it's services (well at least those where there is no better non-X.509 alternative). Right now, one has at least the chance to say that one checks e.g. https://debian.org/ for the issuing CA... or e.g. simply only trust the SPI cert... and then one can be sure to really get what one wants. But Gandi is just another commercial CA... actually, AFAIR, it's even just another intermediate CA from Comodo (which are also known to basically make everyone paying a intermediate) CA... so in the future, everyone in the ladder up from Gandy to the root certs of Comodo will be able to forge just any Debian certs as he likes. Cheers, Chris.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Fri, 14 Mar 2014 22:39:05 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net> :

Extra info received and forwarded to list. Copy sent to Michael Shuler <michael@pbandjelly.org> . (Fri, 14 Mar 2014 22:39:05 GMT) (full text, mbox, link).

Message #204 received at 718434@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net> To: 718434@bugs.debian.org Subject: Re: Bug#718434: ca-certificates: should CAcert.org be included? Date: Fri, 14 Mar 2014 23:34:02 +0100

On Fri, 2014-03-14 at 11:22 +0100, Thomas R. Koll wrote: > Those certificates packaged by and copied over from Mozilla do fullfil their > policy which can be found here: > http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > > In the inclusion section your can find a lot of ways to get accepted by Mozilla, > but CACert has failed to fullfil any of those. And to quote from their policy: > "The burden is on the CA to prove that it has met the above requirements.“ Well that's the "de jure" situation... the de facto situation is that there's only one thing that counts here: money Just read up the case of Turktrust. And the funny part here: With the too-big-to-fail CAs like Verisign, Comodo, Thawrte... one can understand that Mozilla cannot really do much... but Turktrust is like... I mean has anyone ever seen a website with a cert signed by them? I didn't ... any my browser collects all certs ever seen. So they could have easily thrown them out, once they proved clearly to be evil,... but Mozilla choose rather the money than the "security" of their users. > But who knows, with CACert’s move from Australia to Germany we could > see some more action behind the efforts for an audit. Well even with a proper audit, you can't _trust_ CAcert more than you can now,... simply for the same reason that 3 people are already capable of forging any identity... At least for "email certs"... and with respect to server certs... the only "check" CAcert (as well as many commercial CAs - in their cheapest SSL "product") does is: sending an (unsecured) mail to an address in the whois for the domain. Absolutely stupid and insecure. There's the point... you can't really get any trust to all of these CAs. Cheers, Chris.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Shuler <michael@pbandjelly.org> :

Bug#718434 ; Package ca-certificates . (Mon, 17 Mar 201