[arch-general] [arch-dev-public] CAcert dropped from certificate bundle

[Daniel Micay]

On 02/04/14 11:31 AM, Neal Oakey wrote:
> Hi,
> 
> well until now all of this wasn't a problem, so why has it now become one?

It's becoming clearer that CAcert isn't going to be passing a third
party audit any time soon. Our only view into it is the open-source code
they've made available, and messy wiki documentation. The quality of the
code is not exactly comforting - whoever wrote most of it didn't seem to
be aware of prepared statements...

> And well if you have a look at startssl, well they may be offering free
> certs but only single domain and just use the plain "things".
> 
>   * It doesn't allow commercial usage
>   * "only" valid for 1 year

A CAcert certificate isn't trusted in most major browsers or operating
systems, regardless of whether Arch ships it. That's a bigger
inconvenience and makes it quite useless for commercial usage. This
isn't the only example of a free TLS certificate anyway.

>   * located in Israel (don't know if this should be good or bad)

CAcert is located in Australia. Both are US allies and cooperate with US
spying, if your point has something to do with the NSA. It's not like
Australia doesn't have an active spy agency.

> There maybe still quite a few things that have to be worked on at CAcert
> but still I currently would say,
> that I rather trust CAcert signed certs than any other.

You're free to add it if you trust them. Debian and Mozilla don't trust
them, and Pierre has made it clear that he's not in a position to vouch
for them either.

> I mean look at all this fuckup that these firms are doing:
> 
> ... some have been removed already:
> 
>   * Revoking Trust in one ANSSI Certificate (*.google.com)
>   * Revoking Trust in Two TurkTrust Certificates (*.google.com)
>   * Revoking Trust in DigiCert Sdn. Bhd Intermediate Certificate
>     Authority (week certs)
>   * Fraudulent *.google.com Certificate ... => DigiNotar Removal Follow Up
>   * Firefox Blocking Fraudulent Certificates ... => Comodo Certificate
>     Issue -- Follow Up
> 
> ... but I still see many problems:
> 
>   * Chromium still has (all|many) of the cert, which I listed above
>   * still including many 1024 bit keys! (*1)
>   * to many CAs have issued other RootCA (like for e.g.: Tekecom > DFN >
>     every fucking university in Germany (*2))
>   * and how far we still can trust CAs from America, where the NSA seams
>     to be fiddling around in the security of all important firms, I
>     can't really say

The US government is far from the only country with spy agencies. The CA
system won't protect you from national governments, but it does a pretty
good job providing protection from other entities. A certificate
authority like CAcert without even a minimum level of security or
auditing in place is a liability when it comes to this.

Chromium no longer relies on the CA system for Google domains at all, it
simply pins the certificates instead. See
http://www.certificate-transparency.org/ for an example of the work
that's been done on to the CA system. It's a technical solution with
Google's political capital behind it. A CA not implementing it will have
EV (shiny green bar) revoked, and this happens to be a major source of
revenue for them.

> *1:
>> /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt: 1024 bit
>> /usr/share/ca-certificates/mozilla/Equifax_Secure_eBusiness_CA_1.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Equifax_Secure_Global_eBusiness_CA.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/NetLock_Business_=Class_B=_Root.crt: 1024
>> bit
>> /usr/share/ca-certificates/mozilla/NetLock_Express_=Class_C=_Root.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt: 1024 bit
>> /usr/share/ca-certificates/mozilla/Thawte_Server_CA.crt: 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_2.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt:
>> 1024 bit
>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt:
>> 1024 bit
> 
> *2:
> if you ask me, this is just waiting for miss usage, as every university
> (or person which could get access to there CAs) in Germany could issue a
> cert for [your-bank.com]

Trusting CAcert in addition to these certificate authorities will not
improve the situation. At least these certificate authorities are
competent enough to pass third party audits.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140402/4448b704/attachment.asc>