Am 16.09.2013 um 11:46 schrieb "Thijs Kinkhorst" <th...@debian.org>:
> 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 certificates by default. Instead of trusting the SPI root, ca-certificates could include the handfull certificates for its own packages servers, they won't be root, but users can trust them slightly more and it removes the possible insecurity of the SPI roots. I wouldn't mind if a CA created their root, use that to create the set of certificates and want to give out and then burn the private key of the root. No need for an audit as the root private key would only exist mathematically. Distrusting the root and manually approving certificates issued by such a root, is how I do it personally, even though sounds a bit crazy. The fact, or rather glitch, that CACert and SPI are part of ca-certificates mustn't have a weight in a discussion about their inclusion. ciao, tom [0] https://wiki.mozilla.org/CA:How_to_apply the page on CA:Information_checklist is also worth reading [1] or build a three wheel car, they are classified as motorcycles and have rules about as same a suicide booth. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
