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.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to