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

[Neal Oakey]

Hi,

here you have some more detailed informations (see quote).

Greetings,
Neal

Am 02.04.2014 23:40, schrieb Benny Baumann:
> Hi,
>
> Am 02.04.2014 18:33, schrieb Neal Oakey:
>> mit freundlichen Gruessen / best regards
>> Neal Thomas Oakey
>> CAcert Assurer, CAcert Event Organisation
>> CAcert.org - Free Certificates
>> E-Mail: neal at cacert.org 
>>
>> Am 02.04.2014 17:55, schrieb 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
> We are lacking man-power to work on solving the issues found by the
> currently running audit. Details at
> https://blog.cacert.org/2014/03/cacert-appoints-internal-auditor/
>>> they've made available, and messy wiki documentation. The quality of the
> Anybody is free to help clean it up ...
>>> code is not exactly comforting - whoever wrote most of it didn't seem to
>>> be aware of prepared statements...
> Which were not available when most of the code was written. And changing
> the code now - which is being worked on (cf. bug #1260) will take time
> and draw manpower from other places.
>>>> 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
> StartSSL isn't any safer just because most browsers ship them. And given
> their history (3 days from founding to entering the browser stores -
> you're kidding me, right)?
>
> And based on their crypto profile on the website (what their server
> offers) you won't gain any confidence either.
>>> inconvenience and makes it quite useless for commercial usage. This
> Oh, funny. I know first hand that Allianz insurance and Edigas
> consortium accept CAcert as advanced signatures and thus for legally
> signing your business mails. Not to mention all the other businesses
> using CAcert:
> https://blog.cacert.org/2013/07/natural-gas-industry-accepts-cacert-gas-industrie-setzt-auf-cacert/
> http://rootca.allianz.com/en/secumail_calist.htm
> http://wiki.cacert.org/OrganisationAssurance/OrganisationList?highlight=%28CategoryOrganisationAssurance%29
>
> Doesn't look like it for me ... ;-)
>>> isn't the only example of a free TLS certificate anyway.
> Free beer vs. free speech ...
>>>>   * 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.
> Funny. Isn't like Israel is any safer from spying. Not to mention the US
> where Verisign, GoDaddy, GeoTrust, ... and many other big players reside.
>
> Furthermore you should note that there is a motion which was passed
> recently by CAcert Inc.'s board to move the incorperation to another
> country. Which doesn't change the fact that even now the root keys are
> neither in the US nor in Australia - both information which CAN be found
> on the CAcert wiki:
> http://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20140112?highlight=(\bCategoryBoardMinutes\b)
> And the whereabouts of the keys can be found by looking at the
> documentation of the infrastructure systems.
>>>> 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.
> Which I currently do on all my systems; all other certificates are handled TOFU.
>
>>> 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.
> Debian removed them based on arguments sufficient to clear half of the
> Mozilla store. Not to mention that the "there might be bugs in their
> software" argument would cause the Mozilla store to be empty - some
> outcome I'd really prefer to see as it'd be the ONLY honest one.
>>>> 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.
> Having a set of CAs known for having issued fake certificates aren't
> much better either - even IF they happen to have found somebody signing
> them credibility on some piece of paper.
>>> Chromium no longer relies on the CA system for Google domains at all, it
>>> simply pins the certificates instead. See
> Which simply doesn't scale.
>>> 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.
> $$$
>
> And idea is, that CAcert will be implementing something like this too.
> Given enough manpower things would be drastically faster though.
>>>> *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.
> Given how most IT departments in German universities are chronically
> under-funded I doubt signing you some certificate would cost too much
> ... And be it that on of the 64k SANs on the CSR accidentially works for
> some banking website ... how unfortunate. Most IT departments lack the
> practicl knowledge of how to securely operate a CA and given the high
> number of apprentices I really doubt you have to search for too long to
> get such a CSR signed.
>
> Regards,
> BenBE.
>