Bug#718434: ca-certificates: should CAcert.org be included?
Am 14.03.2014 um 10:54 schrieb Klaus Ethgen : > > 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 Description: Message signed with OpenPGP using GPGMail
Bug#718434: ca-certificates: should CAcert.org be included?
Am 13.03.2014 um 17:21 schrieb Christoph Anton Mitterer : > 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 Description: S/MIME cryptographic signature
Bug#718434: ca-certificates: should CAcert.org be included?
Am 16.09.2013 um 11:46 schrieb "Thijs Kinkhorst" : > 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 certifi
Bug#718434: ca-certificates: should CAcert.org be included?
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 : > 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718434: ca-certificates: should CAcert.org be included?
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
