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@xxxxxxxxxx >> >> 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. >
