Debian Bug report logs - #718434
ca-certificates: should CAcert.org be included?

Toggle useless messages

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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.

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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.

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

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.

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>

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

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

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

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

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

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

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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.

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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-----

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/pkcs7-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

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

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-----

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

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

[Message part 1 (text/plain, inline)]

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.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

From: Bas Wijnen <wijnen@debian.org>

To: 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Mon, 17 Mar 2014 03:06:04 +0100

[Message part 1 (text/plain, inline)]

On Thu, Mar 13, 2014 at 01:03:23PM +0000, Michael Shuler wrote:
>    * No longer ship cacert.org certificates.  Closes: #718434, LP: #1258286

I was not aware of this bug until my browser started refusing my cacert
certificate at the latest upgrade.  I see there has been a long
discussion about this, and I've read a significant part of it.  I
understand the viewpoints, but have something to add which is currently
missing from the discussion IMO:

As you may be aware, Poul-Henning Kamp has been talking about browser
security in this year's edition of FOSDEM[1][2].  One of the things he
specifically mentioned was that it would be great if all web traffic was
encrypted.  And really, self-signed certificates are good enough!  MITM
attacks may happen, but will be extremely rare; the choice of encrypting
vs not encrypting should be an easy one.

However, we all know how all browsers scare everyone but the most
persistent away from visiting a site which uses an untrusted
certificate.  Because of this, most of the web is still unencrypted: who
wants to scare their users away?  The other option is to get a
certificate, which costs money.  Except with CAcert.

Because of this, CAcert is the best way to push websites in the
direction of encrypting all websites.  Sure it'd be better if Mozilla
would accept them.  It would be even better if Mozilla would stop
screaming at the user when a self-signed certificate is encountered.
But we, as Debian, don't have control over Mozilla.  We can ask them,
and they might listen.  In the mean time, we can do our own part in
making the web better.

Yes, I understand that CAcert's code and procedures are less secure than
they should be.  I don't care.  First priority is to get the web
encrypted.  Trusted certificates is secondary.  As long as browsers
don't reasonably allow self-signed certificates, I think we should
accept any and all certificates as trustworthy; certainly the ones from
a community-driven CA.  (As noted, the current selection doesn't seem to
filter for security anyway.)

Thanks,
Bas

[1] https://fosdem.org/2014/schedule/event/nsa_operation_orchestra/
[2] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm

[signature.asc (application/pgp-signature, inline)]

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

From: "Thijs Kinkhorst" <thijs@debian.org>

To: "Bas Wijnen" <wijnen@debian.org>, 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Mon, 17 Mar 2014 09:54:47 +0100

On Mon, March 17, 2014 03:06, Bas Wijnen wrote:
> The other option is to get a
> certificate, which costs money. Except with CAcert.

This is not true. There are several CA services recognised by the major
browsers and thus the ca-certifcates package which offer free as in money
SSL certificates; and there are several more that offer them at very low
prices.


Thijs

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

From: sergio <mailbox@sergio.spb.ru>

To: 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Mon, 17 Mar 2014 13:01:52 +0400

On 03/17/2014 12:54 PM, Thijs Kinkhorst wrote:

> There are several CA services recognised by the major browsers and
> thus the ca-certifcates package which offer free as in money SSL
> certificates; and there are several more that offer them at very low
> prices.

Examples, please. Except Startcom.



-- 
sergio.

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

From: Ivan Shmakov <ivan@siamics.net>

To: 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Sat, 22 Mar 2014 13:42:08 +0000

>>>>> Bas Wijnen <wijnen@debian.org> writes:
>>>>> On Thu, Mar 13, 2014 at 01:03:23PM +0000, Michael Shuler wrote:

 >> * No longer ship cacert.org certificates.  Closes: #718434, LP:
 >> #1258286

[…]

 > Yes, I understand that CAcert's code and procedures are less secure
 > than they should be.  I don't care.  First priority is to get the web
 > encrypted.  Trusted certificates is secondary.  As long as browsers
 > don't reasonably allow self-signed certificates, I think we should
 > accept any and all certificates as trustworthy; certainly the ones
 > from a community-driven CA.  (As noted, the current selection doesn't
 > seem to filter for security anyway.)

	There’re two issues with that.  First of all, accepting some
	“random” certificates may give the users some false sense of
	security.  Then, I’d like to note that a compromised CA may very
	well be used to issue an “example.com” certificate /even though/
	example.com may already have a valid certificate from some other
	(non-compromised) CA?  And the TLS-enabled user agents generally
	have no means to discern such “fake” certificate from the
	“genuine” one.  That is: the security of the Web is essentially
	the security of /the least secure/ CA of those one trusts.

	… That being said, could someone please remind me when Debian
	has itself passed a security audit for the last time?  Or,
	scratch that, – when it was the last time the TLS-related Debian
	binary packages were audited?  (And sorry, “related” also means
	the entire GNU toolchain – GCC, etc. – since you can’t really
	trust a binary produced by a compromised compiler, can you?)

	TIA.

-- 
FSF associate member #7257

Message #229 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: fixed in ca-certificates 20140223

Date: Sun, 23 Mar 2014 02:50:04 +0100

[Message part 1 (text/plain, inline)]

On Sat, 2014-03-22 at 13:42 +0000, Ivan Shmakov wrote:
> First of all, accepting some
> “random” certificates may give the users some false sense of
> security.

This is true, and also a reason why I'm really convinced of the argument
encrypt/sign,... even if it's not trusted...

Especially the argument that the only problem one has are MitM attacks
sounds kinda stupid.... since everyone that can intercept your traffic
(which an attacker would need to be able anyway - even if all was
clear-text)... can also easily do MitM attacks...


But what you talk about: "false sense of security"... that goes much
farther...

The whole current X.509 based strict-hierarchical trust model with
gazillions of CAs gives a false sense of security.
Especially when it's controlled by companies like MS, Apple, Mozilla for
whom only money counts and who are themselves under the control (just as
the CAs as well) of governments.
And especially when you have CAs in the list, for which you know for
sure, that they will happily assist their governments in forgery ...
CNNIC, Turktrust,... just to name the most obvious...


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

From: Dmitry Smirnov <onlyjob@debian.org>

To: debian-devel@lists.debian.org

Cc: 718434@bugs.debian.org

Subject: ca-certificates: no more cacert.org certificates?!?

Date: Sun, 23 Mar 2014 16:54:49 +1100

[Message part 1 (text/plain, inline)]

I've just noticed that cacert.org certificates was removed from
"ca-certificates" a month ago. From changelog [1]:

    * No longer ship cacert.org certificates.  Closes: #718434, LP: #1258286

I'm disappointed by this decision and from #718434 I don't get
a clear picture what is wrong with cacert.org. For years we were
shipping their certificates and IMHO there should be a damn good
reason to stop doing so. I wish maintainer would state the reason for
removal in cahngelog.

Is situation with cacert.org certificates dramatically worsened lately?
Any security flaws were discovered?
What we're gaining from dropping their certificates?

Did we notify cacert.org about our intentions to drop their certificates?
What were their comments? Did they provide time frame to address our concerns?

Cacert.org web of trust model is very similar to ours. To me it is
essentially more trustworthy than what for-profit CAs offer.
Cacert.org (as the only non-profit community managed CA) needs our support.
How dropping cacert.org certificates is going to benefit our communities?

The following comment highlight some benefits of providing cacert.org
certificates:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#209

I want cacert.org certificates to raise no warning in browsers. This way we
can encourage use of cacert.org certificates as alternative to self-signed
certificates and therefore promote the use of HTTPS.
Users are supposed to check certificate properties for encrypted connections
if/when they want to check certificate authenticity. I think dropping
cacert.org did more harm than good. Perhaps it's better to promote packages like
"xul-ext-certificatepatrol" rather than punish cacert?
After all I'm sure cacert.org team is doing their best just like we all do
in Debian.

[1]: http://metadata.ftp-master.debian.org/changelogs/main/c/ca-certificates/unstable_changelog

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

The most fatal blow to progress is slavery of the intellect. The most
sacred right of humanity is the right to think, and next to the right to
think is the right to express that thought without fear.
        -- Helen H. Gardner, "Men, Women and Gods"

[signature.asc (application/pgp-signature, inline)]

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

From: ianG <iang@iang.org>

To: 718434@bugs.debian.org

Subject: Re: ca-certificates: should CAcert.org be included?

Date: Sun, 23 Mar 2014 14:30:52 +0000

Hi all,

(replying for myself, not any organisation.)

I wasn't aware of this debate, but now that it is closed, maybe it is
helpful to put some context on it.



The essential decision you have to take, and have taken is this:

     Follow Mozilla's lead, or not?

Having taken it, I can say two things.

Firstly, that this is probably what you have to do:  follow Mozilla's lead.

> Realistically I cannot vouch for any of the CAs we ship. That's one
> reason why we push that responsibility upstream to e.g. the Debian
> project or Mozilla.

In economic terms, the Linux distros don't really have the capability to
duplicate the work that goes on behind the scenes, the work to analyse
the choices, and the work to build some sort of cohesive policy in
analysing CAs.  And nobody else has a similar project (I don't say open
project) to follow.

Your choice is only Mozilla, and you follow it.



Secondly, that it's wrong.  In contrast to the above, the practice of
following Mozilla is wrong by any objective other than the economically
efficient thing to do, as a distro, as Debian, as an organisation.  As a
community of open source, user-oriented volunteers, it's wrong.

Therein lies the rub.  Why?  This gets at the whole problem of PKI, and
this is what makes people tear their hair out for thinking too much
about it.

Assuming you wish to tear your hair out, read on.  No shame in keeping
your hair and writing code instead, that's what I should be doing.



The easiest way to look at the problem is this:  Mozilla also has the
same problem as Debian.  Which is to say, Mozilla hasn't the resources
to analyse the CAs, so it follows audit.

Which leaves us at audit's door.  And now we get to the core issue:
audit is a failed process.  It is failed for many reasons but the key
one for PKI is this:

     Audit follows a script that isn't germane to users' security.

The reason it is not germane to users' security is that it is written by
the insiders -- the CAs are the biggest providers of information as to
how they should be audited, they dominate on most or all levels, and
they pay big money for the privilege.  So clearly, they provide
information that helps themselves and not necessarily anyone else.  And
they argue against any changes against their interests.  And, they're
good at their job.  And, they pay for the right result.

Surely, you say, don't Mozilla and other vendors check all this to make
sure it is good for users?  No, not really, not *effectively*.
Mozilla's policy primarily follows the concept of an audit [0].  They do
have in the policy the ability to drop a CA, if it is detrimental for
the users.  They can put pressure on the CAs when clear problems arise
(e.g., the secret sub-CAs).  They participate in closed-door sessions to
write new audit processes, so they can influence.

But in essence they have never made tangible what the user's interest
means, other than ... audit, and they've never deployed a critic of
audit on the job.  For various reasons, most vendors do not have, never
had, and likely never will have deployed the capability to understand,
regulate and understand what audit really is about.  Nor do they care,
it's not their business.



To be fair, PKI is hard to understand.  I didn't understand it when we
were writing the Mozilla policy 9 years back, and I didn't understand it
for the first year or two of my efforts.

So how is it that I know, now?  We know now because CAcert did something
that no other CA did -- it broke ranks and asked a non-PKI interested
party to do the Audit.

That person was David Ross.  Who was a user.  He realised that the
existing criteria were not germane, so he wrote his own, which we call
DRC.  He wrote it from his viewpoint of what a user needed or could
sustainably argue was important for users, using long experience as a
systems engineer and quality reviewer.  In DRC there is one key element
(stretched across multiple parts) which we call RLO:

    The CA has published the Risks, Liabilities and Obligations of the
parties [1].

That one key element, RLO for Risks, Liabilities and Obligations, broke
CAcert.  It forced a total re-design to cope.  You can see the results
in the member's agreement, CCA, which was specifically written to state
and carry the RLO.  And, to make members into 'parties' a key point that
became the crux of the infamous root licence [2].

RLO also breaks PKI as we know it.  What does every other CA's RLO look
like?  Buried.  They cannot pass DRC.  What does Mozilla's look like?
Not so buried, they now have, for many years, an End User Licence
Agreement that states their liabilities are zero, but the implication is
buried.  Why are their liabilities disclaimed?  Because, once you go
looking deep at the CAs, you discover that CAs disclaim all liabilities
and therefore if there is any snafu, the vendor is on the hook.  Mozilla
must also disclaim because it chose the CAs, and it's the counterparty
with the user, not the CAs.  Are you paying attention, Debian Legal Officer?

Which brings up the philosophical question of what certificates can be
relied upon for?  The answer is nothing, if it means money.



Except at CAcert.  In CAcert's statements, they say "file a dispute" and
they defer the process over to an Arbitrator.  They don't say their
liabilities are infinite, but they do give you your day in court and an
Arbitrator has wide powers.  If you're not a member, you still get your
day in court, and while liabilities to you are probably still zero [3],
and a judgement may not recompense you, this does not mean that the
certificate holder is held harmless.

Which may be why some people say they trust CAcert and no other CA.

At CAcert, *there is recourse*.  This recourse is over everything, all
the time, every act;  and it shows through in the professionalism and
care which people take.  At CAcert, certificates mean something, and you
will find that meaning -- before an Arbitrator.

Whereas, other CAs have totally buried recourse.  They disclaim
liability totally for everything, they hide it from you, and they market
certificates *as if* you can rely on them.  Try it!  If you ask about
the legal contract, the shutters go up.  It might be an American
paranoia to never talk about liability, but in practice this is what
happens -- no CA will talk about its liabilities to you.  It is
impossible to talk seriously about the benefit to the user without
talking about the liability when something goes wrong, and it is
therefore impossible to talk *seriously* to any CA or vendor about the
real meaning of the certificates or reliance in effect as opposed to the
wordage.



How can this be?  Surely audit would have picked this up?  It does and
it did.  CAcert's audit process did pick it up and CAcert worked for
about 3 years to build the arrangement where it can protect itself (very
important) its members (as important) its vendors (also considered) and
also the users who weren't members (Principles say this is important too
[4]!).

Other CA audits did pick it up;  but they didn't respond *in the user
interest*.  They are focussed on protecting the CAs [5]!  And, they are
very good at their job.



For the users, nothing.  This is why it is wrong.  The process is
basically rigged to ensure the business of CAs, in that nothing that can
ever go wrong can be legally bound back to the CAs.  Now, happily
extended to the vendors [6].  But the users are screwed.

Users, go phish yourselves.

Perhaps there isn't so much excitement at CAcert to push forward on the
audit, after I withdrew, but I personally am comfortable with that
because it doesn't add to the user process that we hold paramount at
CAcert.  The audit is basically antithetical to the spirit of an open
source, community project like Debian, like CAcert, and even like
Mozilla, maybe.  Only David Ross's efforts ever did anything *for the
user* in the world of PKI, and his work is locked out.

Sour grapes, you might say, and I'm not going to challenge that.  I
spent 3 years of my life to make it happen, and had to let it go.
Fighting against the juggernaut isn't a lot of fun, and as I suggest to
you, debian, just following Mozilla is the right, only choice you have
available.

Rather than getting involved in a broken, corrupt process, you should be
writing code.  And so should I!  Back to it.



iang,
sometime auditor of CAcert, now not really involved, and speaking for
myself only.



[0] Mozilla's policy:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

[1]
http://svn.cacert.org/CAcert/Audit/AuditCriteriaOnRisksLiabilitiesObligations.html

[2]  The root licence is a very tricky document.  Where we get into
legal trouble here is that users of certificates -- you out there in
debian land -- may or may not be parties to a contract.  Other CAs will
tell you that you are a relying party, which means you have a contract
with them, that indemnifies them totally.  If you dispute this, *you
haven't got a contract and therefore you cannot sue them*.  This is a
deception.  In CAcert, we do not deceive (it's in Principles!) and we do
not tell you that you are a relying party when you have no agreement
with us.  We haven't seen you, you haven't seen us in your browser (!!),
how can there be a contract???

Hence, what there is, is an open offer licence along the lines of a
distro licence, and you are invited to arbitrate, but CAcert's
liabilities aren't going to be much.  Because of the RLO issue, it
cannot and must not promise you are a party when you are not, and that
you can rely when the term is a deception.  Very annoying, but the trick
is to ignore that FOSSL comparison and compare it instead to any other
CA.  Are you getting uncomfortable yet?  Those distros that criticise
CAcert on the basis of their "non-FOSSL-approved licence" can't even
find the contracts of the other CAs.

[3] If you want to learn why liabilities for CAs have to be set to zero,
then try section 4 in long thing:
http://iang.org/papers/open_audit_lisa.html

[4] Principles are here:
https://svn.cacert.org/CAcert/principles.html

[5] WebTrust used to have a clause in criteria that suggested that
relying parties should indemnify the CA (!?) so liability avoidance was
always part of the process.  In later generations even that was dropped,
from memory.  Embarrassing, or what?.  You can see this with Thawte when
they dropped the WoT back in 2009 or so -- before that, the auditor
declined to audit it because the liabilities weren't properly handled --
which is to say, Thawte took on non-understood liabilities that weren't
properly zero'd out.  CABForum can be seen as a cartel to ensure that
liabilities are properly controlled in the face of phishing (which is
what the vendors thought they were doing...).  Once the vendors figured
out that they were potentially on the hook for unlimited damages, they
got the CABForum to put in an indemnification for them, CABForum's
Baseline Requirements section 18.2.

[6] I'm not being sarcastic about this, I agitated at Mozilla to get
their liabilities set to zero because they had been screwed by the CAs
as well.  At least they are now aligned at zero, but once it wasn't so.

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

From: Bas Wijnen <wijnen@debian.org>

To: 718434@bugs.debian.org, Thijs Kinkhorst <thijs@debian.org>, Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Mon, 24 Mar 2014 04:27:31 +0100

[Message part 1 (text/plain, inline)]

On Mon, Mar 17, 2014 at 09:54:47AM +0100, Thijs Kinkhorst wrote:
> On Mon, March 17, 2014 03:06, Bas Wijnen wrote:
> > The other option is to get a
> > certificate, which costs money. Except with CAcert.
> 
> This is not true. There are several CA services recognised by the major
> browsers and thus the ca-certifcates package which offer free as in money
> SSL certificates; and there are several more that offer them at very low
> prices.

I looked, but didn't find them.  I believe you that they exist, but
there are others which shout they are free, but when you go to them that
doesn't seem to be true.  When I found CAcert, I gave up on those
misleading companies.

Given the situation (described in much more detail than I was aware of
by IanG), I think CAcert is by far the best certificate authority there
is, especially for an organization such as Debian.

I would drop all other CAs from the list before dropping CAcert.

On Sun, Mar 23, 2014 at 02:50:04AM +0100, Christoph Anton Mitterer wrote:
> On Sat, 2014-03-22 at 13:42 +0000, Ivan Shmakov wrote:
> > First of all, accepting some
> > “random” certificates may give the users some false sense of
> > security.
> 
> This is true, and also a reason why I'm really convinced of the argument
> encrypt/sign,... even if it's not trusted...

I don't understand what you're saying here.

> Especially the argument that the only problem one has are MitM attacks
> sounds kinda stupid.... since everyone that can intercept your traffic
> (which an attacker would need to be able anyway - even if all was
> clear-text)... can also easily do MitM attacks...

No.  The basis of a man in the middle attack is that both parties talk
to you and think you are the other end of the communication.  They
encrypt their traffic against YOUR public key, instead of the actual
recipient's key.  If they encrypt it with the right key, you can see the
encrypted traffic but not read it.  You could modify the packets, but
the only effect would be that they would fail to decrypt.

A certificate authority does not provide the encryption keys.  It only
puts signatures on them.  Without any CA, you can still encrypt if you
have the target's public key.  The problem that a CA tries to solve is
"getting the public key that actually belongs to the computer I want to
connect to".  An evil CA cannot read your traffic (unless they are in
the path of your communication).  They can only convince users that some
key is really yours.  And that is only useful if they are in the path of
communication, so they can alter the packets.

So yes, MitM attacks are the only problem that CAs are defending
against, and they are also the only thing to consider when trusting a
CA.

Thanks,
Bas

[signature.asc (application/pgp-signature, inline)]

Message #249 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: fixed in ca-certificates 20140223

Date: Mon, 24 Mar 2014 15:16:51 +0100

[Message part 1 (text/plain, inline)]

On Mon, 2014-03-24 at 04:27 +0100, Bas Wijnen wrote:
> On Sun, Mar 23, 2014 at 02:50:04AM +0100, Christoph Anton Mitterer wrote:
> > On Sat, 2014-03-22 at 13:42 +0000, Ivan Shmakov wrote:
> > > First of all, accepting some
> > > “random” certificates may give the users some false sense of
> > > security.
> > 
> > This is true, and also a reason why I'm really convinced of the argument
> > encrypt/sign,... even if it's not trusted...
> 
> I don't understand what you're saying here.

I just agreed to Ivan's opinion... right now many people say "it's
better to do crypto, even if it's anonymous and you have no idea who
you're talking to"... their reason is usually on of
- the attacker may miss the point where the communication starts and
therefore the point where he could do an MitM
- even if the attacker does MitM, he would need more computing power
(and therefore money) to decrypt everything.

The 2nd argument is IMHO very weak... and the first one... well this
might help against some people just sniffing around there and then...
but not against the big attackers like NSA & Co.


> No.  The basis of a man in the middle attack is that both parties talk
> to you and think you are the other end of the communication.  They
> encrypt their traffic against YOUR public key, instead of the actual
> recipient's key.  If they encrypt it with the right key, you can see the
> encrypted traffic but not read it.  You could modify the packets, but
> the only effect would be that they would fail to decrypt.
Sure... o.O

But that's just the point...
When an attacker sits on the line between A and B,.. and they don't
encrypt... than obviously he can read/tamper with everything.

Now people say, "encryption still helps, even when it's anonymous - and
that's the scenario we were talking about".
Does it really?

If the attacker sits on the line between Alice and Bob (which he
apparently does, since he was able to read the unencrypted stuff)... and
if Alice and Bob don't verify their identities... then he can to MitM...
just as you explained it above.

So I'd say... anonymous encryption does not really help that much... at
least not against someone who constantly sits on the line and watches
all traffic (which NSA&friends surely do)
It gives rather a wrong sense of security.


> A certificate authority does not provide the encryption keys.  It only
> puts signatures on them.  Without any CA, you can still encrypt if you
> have the target's public key.
Well sure.. but what do you want to tell us? Of course you can.. but
nobody usually manually trusts X.509 certs (i.e. non-CA-certs)

> An evil CA cannot read your traffic (unless they are in
> the path of your communication).
Sure... but they can create any identity ... and getting somehow into
the path of a communication.. or tricking one of the peers to a wrong
path is usually the easier part.



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

From: Bas Wijnen <wijnen@debian.org>

To: 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Tue, 25 Mar 2014 18:58:31 +0100

[Message part 1 (text/plain, inline)]

On Mon, Mar 24, 2014 at 03:16:51PM +0100, Christoph Anton Mitterer wrote:
> I just agreed to Ivan's opinion... right now many people say "it's
> better to do crypto, even if it's anonymous and you have no idea who
> you're talking to"... their reason is usually on of
> - the attacker may miss the point where the communication starts and
> therefore the point where he could do an MitM
> - even if the attacker does MitM, he would need more computing power
> (and therefore money) to decrypt everything.

No, the point is that an attacker is detectable.  Do you think the NSA
does MITM attacks on all connections?  I seriously thought that they
might.  So when I traveled from the US to the Netherlands, I took a copy
of the key of my machine in the Netherlands, as seen from my browser in
the US.  I compared that copy when I was in the Netherlands, and it
matched.

If the NSA starts doing this, someone will catch them.  That will be big
news and everyone will start checking their keys.  And if none of them
match, things will be fixed.  As long as they don't do it, checks like
the one I did will confirm that nothing is wrong.

Well, not exactly, of course.  It is still very likely that they are
trying to (and also that they succeeded to) put back doors into the
encryption protocols, or at least their implementations.

> But that's just the point...  When an attacker sits on the line
> between A and B,.. and they don't encrypt... than obviously he can
> read/tamper with everything.

Depending on what you mean by "sitting on the line".  They can always
read, but to tamper they need to sit "in" the line, not just on it.
They have to make sure the original packets don't reach their
destination.  I take it that's what you mean.

(Note that this is a much smaller group of machines; for example, I can
read all traffic on the subnet of my block of houses, but I can't
effectively tamper with it.)

> If the attacker sits on the line between Alice and Bob (which he
> apparently does, since he was able to read the unencrypted stuff)... and
> if Alice and Bob don't verify their identities... then he can to MitM...
> just as you explained it above.

But if they start to doubt, they can check if they have been attacked,
by comparing their keys through an independent channel.  There will have
been a small window where their communication was intercepted, but
that's still much better than having everything always public.

> So I'd say... anonymous encryption does not really help that much...
> at least not against someone who constantly sits on the line and
> watches all traffic (which NSA&friends surely do) It gives rather a
> wrong sense of security.

Anonymous encryption is better than no encryption.  And it gives actual
security.  Certainly against people who are only listening (of which
there are many), and (with a small delay where you might send sensitive
data to the NSA) also against MITM attacks, because some people will
check some keys every now and then.  If any of them is found to be under
attack, more checks will be done; if many of those will fail, all hell
will break loose.

And the NSA is not stupid.  They know this.  So they aren't going to
try.  Instead, they are claiming that "it doesn't really help anything"
and "it only gives a false sense of security", to convince people that
not encrypting is better than encrypting with unchecked keys.  Sure they
like it when the entire internet is unencrypted, it makes their work
easier.  It does not however provide any benefit to us or our users.

> > A certificate authority does not provide the encryption keys.  It only
> > puts signatures on them.  Without any CA, you can still encrypt if you
> > have the target's public key.
> Well sure.. but what do you want to tell us? Of course you can.. but
> nobody usually manually trusts X.509 certs (i.e. non-CA-certs)

You're claiming that having an evil CA in the list means that my
communication is in danger of being eavesdropped.  I'm saying that this
is nonsense, because:

> > An evil CA cannot read your traffic (unless they are in
> > the path of your communication).

You are saying that the NSA has control over evil CAs, and also is in
the path of communication.  So they can eavesdrop.  Technically this is
true.  But there are two things to consider:

1. Due to the fact that they would be detected if they tried this on a
   large scale, they won't actually do this.
2. Your conclusion that because the NSA can eavesdrop, we should allow
   everyone else too (by not encrypting at all) is beyond ridiculous.

Thanks,
Bas

[signature.asc (application/pgp-signature, inline)]

Message #259 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: fixed in ca-certificates 20140223

Date: Tue, 25 Mar 2014 23:23:02 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2014-03-25 at 18:58 +0100, Bas Wijnen wrote:
> No, the point is that an attacker is detectable.
Why should he be?
And even if he was... if I already sent my valuable data, then it's too
late.


> Do you think the NSA
> does MITM attacks on all connections?  I seriously thought that they
> might.
Well the question is less whether they actually try it with any
connection... which is of course unlikely since people would notice that
far to easy... the question is rather whether they could do it with all
connections... and I guess that might be the case... the only thing they
need to do is to hijack only such connections for which they know no
verification will be made.


> If the NSA starts doing this, someone will catch them.  That will be big
> news and everyone will start checking their keys.
I doubt that... and how should it work anyway? How can I check the
public key of my e.g. bank?
Right now, only by trusting Verisign&friends... which again are all
under the control of NSA&friends.


> Well, not exactly, of course.  It is still very likely that they are
> trying to (and also that they succeeded to) put back doors into the
> encryption protocols, or at least their implementations.
Sure but that's another field...



> Depending on what you mean by "sitting on the line".  They can always
> read, but to tamper they need to sit "in" the line, not just on it.
> They have to make sure the original packets don't reach their
> destination.  I take it that's what you mean.
> 
> (Note that this is a much smaller group of machines; for example, I can
> read all traffic on the subnet of my block of houses, but I can't
> effectively tamper with it.)
Well if one has to assume that they sit "in" the big internet exchange
points... this already gives them a lot...


> But if they start to doubt, they can check if they have been attacked,
> by comparing their keys through an independent channel.
Well but that simply doesn't happen, does it?
At least since Snowden, all world should really know: NSA&friends spy
_everything_ ... I mean most of use expected it for sure before... but
now there is no way to not know.

And what changed?
Well we still have the broken X.509 strict hierarchical trust model,...
and it won't go away very soon.

Of course the NSA won't issue forged certs (by forcing verisign&friends)
at large (because that would be rather easily noticed) but they will do
so for targets worth it.

So people must have your "doubts" by know, but nothing really changes.
Actually the contrary... like e.g. Debian who puts its own certificates
under some commercial CA now, instead of using its own, which people
could really trust (well at least as much as they can trust Debian
itself).


> If any of them is found to be under
> attack, more checks will be done; if many of those will fail, all hell
> will break loose.
You can be sure that they do all this... and no hell broke loose.



> to convince people that
> not encrypting is better than encrypting with unchecked keys.
Well that's not what I said... I rather say the later is simply not
enough.


> You're claiming that having an evil CA in the list means that my
> communication is in danger of being eavesdropped.  I'm saying that this
> is nonsense, because:
> 
> > > An evil CA cannot read your traffic (unless they are in
> > > the path of your communication).
> 
> You are saying that the NSA has control over evil CAs, and also is in
> the path of communication.  So they can eavesdrop.  Technically this is
> true.  But there are two things to consider:
> 
> 1. Due to the fact that they would be detected if they tried this on a
>    large scale, they won't actually do this.
Well first... why is an attack only a problem if it's done at large
scale?
If the NSA does this only for the Snowdens, Applebaums, etc. ... then
this is enough for them...

Secondly,... "being detected" in that case means, that someone
trustworthy regularly scans for forged certificates... (in the sense of
having a different fingerprint, than the ones from the same CA, which
are however known to be in the possession of their rightful owner).

- This is difficult by the mass of certificates... even for single
companies like google you have gazillions of domains and even more
certs...
This is the reason why programs like certificate patrol are only little
helpful in practise.

- It would need to mean, that this someone is not under the control of
such government (also, not necessarily the case).

- It would need to mean, that that someone does actually know the
correct cert (if he only ever saw the forged one, he will never notice
it).

- And it would need to mean that the rightful owner is not evil... or
not forced to be evil (by law)... which we again know is the case at
least in the US.


So you may be "lucky" to notice such forgery... but there is no
guarantee.



Anyway... the topic of that bug was rather the CAcert certificate... and
I think Debian is doing very bad if it tries to give any "guarantee"
about trustworthiness of it's shipped certs...
It simply cannot (neither can Mozilla or anyone else)...
As such, ca-certificates would be better off being a collection of well
known certificates, who are known to be "valid" (i.e. the ones they
claim to be).

I'm not saying that CAcert is secure or trustworthy (actually I wouldn't
use it for my own "security critical" services - neither would I use any
other CA not under my personal control)... but it's not less secure than
any other CA we ship.
And right now, the only thing we do is taking away the user's
possibility to retrieve root certificates in a secure way.

We should not remove certs... we should add more, like CERN CA, TACAR
TERENA, etc.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

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

From: Bas Wijnen <wijnen@debian.org>

To: 718434@bugs.debian.org

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Wed, 26 Mar 2014 01:56:15 +0100

[Message part 1 (text/plain, inline)]

On Tue, Mar 25, 2014 at 11:23:02PM +0100, Christoph Anton Mitterer wrote:
> On Tue, 2014-03-25 at 18:58 +0100, Bas Wijnen wrote:
> > No, the point is that an attacker is detectable.
> Why should he be?

Because I can store the certificate, go somewhere else, and check if my
stored version is identical to the version that I receive from there.

In that sense, self-signed certificates are actually more safe; they
produce a new warning when the certificate changes.


This is about "let's encrypt every single connection on the web".  We're
talking about people like me.  I have a website with a CAcert
certificate.  I can check that my key as it is stored on my server (in
my house) is the same key that I get when I visit the site from the US
(if there's one place where the NSA should have no problem getting
access it's there).

> Well if one has to assume that they sit "in" the big internet exchange
> points... this already gives them a lot...

If they are in the building and can tap the wire, but not modify the
packets, then an encrypted link is unreadable for them.

> > But if they start to doubt, they can check if they have been attacked,
> > by comparing their keys through an independent channel.
> Well but that simply doesn't happen, does it?

I recently did it, I'm guessing I'm not the only one.

> So people must have your "doubts" by know, but nothing really changes.

I'm talking about posts on Slashdot from people saying "I checked my
certificate from home and from the US, and they were different,
therefore 'someone is doing something naughty'".  I haven't seen any of
those.

> > to convince people that not encrypting is better than encrypting
> > with unchecked keys.
> Well that's not what I said... I rather say the later is simply not
> enough.

Fair enough, you didn't say it was better, but you did disagree with
"it's better to do crypto, even if it's anonymous and you have no idea
who you're talking to".

... which leads to the conclusion that "it's not better to do crypto" in
that situation (which isn't the same as "better not to", but close
enough, I would think).

> Well first... why is an attack only a problem if it's done at large
> scale?

Because the data we're talking about is approximately the definition of
uninteresting.  It's all the connections to people's private websites,
personal chat sessions, that sort of stuff.  The only way it is useful
for them, is when they gather huge amounts of it and filter it.

> If the NSA does this only for the Snowdens, Applebaums, etc. ... then
> this is enough for them...

In that case you can stop worrying.  The NSA has billions of dollars at
their disposal.  If they really want some information, they will get it.
There is no way we can prevent that, and we shouldn't waste our time on
trying.

Expect the NSA to always be able to read everything.  It may not always
be true, but who cares?  We don't have the power to stop them.

What remains, is a mostly unencrypted web.  We should fix that.  The NSA
isn't the only one who wants to listen, and even if we can't stop the
NSA, we can still stop most others.  The only way to do that, is by
making encryption easy and functional.  Dropping CAs from the list is
counterproductive.  Especially with CAcert, which I expect to be
disproportionally popular with Debian users.

> I'm not saying that CAcert is secure or trustworthy (actually I wouldn't
> use it for my own "security critical" services - neither would I use any
> other CA not under my personal control)... but it's not less secure than
> any other CA we ship.

Unless you are really large (like Google or Microsoft), a CA under your
personal control is useless.  The point of a CA is that your visitors
get the root key through an independent trusted channel.  If you need to
send your personal root key to all your visitors, you can as well send
them the key you use for encryption.

> And right now, the only thing we do is taking away the user's
> possibility to retrieve root certificates in a secure way.
> 
> We should not remove certs... we should add more, like CERN CA, TACAR
> TERENA, etc.

On that we agree, then. :-)

Thanks,
Bas

[signature.asc (application/pgp-signature, inline)]

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

From: Raphael Geissert <geissert@debian.org>

To: Bas Wijnen <wijnen@debian.org>, 718434@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>

Subject: Re: Bug#718434: fixed in ca-certificates 20140223

Date: Wed, 26 Mar 2014 14:13:22 +0100

Hi,

On 26 March 2014 01:56, Bas Wijnen <wijnen@debian.org> wrote:
> On Tue, Mar 25, 2014 at 11:23:02PM +0100, Christoph Anton Mitterer wrote:
> > Anyway... the topic of that bug was rather the CAcert certificate...

Exactly. Please stay on topic.

Whatever else you (and this goes to everyone who has posted or wants
to post) want to say that it is not strictly within the topic of this
report, please refrain yourself from writing it here and send it
elsewhere.

Thanks.

-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Send a report that this bug log contains spam.