On Sat, 2014-06-21 at 16:40 +0200, Tollef Fog Heen wrote: > That user trusts us to build a distro fairly competently, something we > have a history of doing. Well it's not that we'd have never made mistakes there... > That user would then trust us to run a CA competently, something we as a > project don't have a history of doing, so they have no reason to believe > we can do so. I don't think it's much more difficult to secure e.g. our package management infrastructure ("secure APT") than securing a CA... on the secure APT side we have similar things... keys, things we "sign" (i.e. who is a DD and who not)... so why should we be capable to do the one thing but not the other. > Running a good CA is not a trivial effort. Well first our CA would be much simpler than any generic CA... we could simply make sure to only sign debian.[org|net|...] CSRs... which would already take away any burden of really verifying identities (on thing where CAs fail most often). So if we have one completely offline node, which has the root cert key and issues any certs... and another completely offline node, which checks whether only debian.[org|net|...] certs were issued (fairly easy)... we can at most compromise our own service (which we can do anyway). And I don't think that running a small CA as our's would be is technically that extremely difficult. Actually I think we can do much better than most commerical CAs. - since we'd only have to issue rather few certs this could be done completely manually on offline systems, such wich are even updated only offline via USB stick - since we're all over the world, we can place it in a "secure" country (i.e. no gag order, national security letters, etc.) And to be honest,... I think you greatly overestimate what _all_ CAs would be doing do secure their own infrastructure (and it doesn't help at all if few out of the >150 CAs in Mozilla does a good job): - we've seen cases of CA's accidentally creating intermediate CAs - CAs accidentally and/or intentially creating forged certs - CAs that hat their main systems connected closely to the internet (DigiNotar) - etc. pp. I think even if we'd try, we couldn't possibly do much worse ;-) > > Of course this still doesn't solve the problem of e.g. browsers, that > > they have gazillions of CAs, and each could issue forged certs for > > Debian hosts, but at least it technically allows the user (or programs > > like apt-listbugs) to _really fully securely_ contact Debian services > > via TLS/SSL with X.509 - something which is not possible with > > GANDI/CAcert or any other non-Debian-managed CAs. > > Either cert pinning or DTLSA records would be better solutions here. Not sure what you mean with cert pinning... and I guess DTLSA is a typo for TLSA (i.e. DANE)? Well I'm not sure what I should think about DANE... I mean DANE is based on DNSSEC, which has the same inherent problem than X.509 - it's a strictly hierarchical trust hierarchy. You're always dependant on the registry being good not evil. I doubt that it's easy to forge the root zone itself (since far to many people monitor it for any changes)... but the TLD zones? I mean you basically have no chance to rule out that a registry like Verisign doesn't generally or selectively send out forged DNS[SEC] RRs... The only thing one can do in order to protect against this is to use DLV and place Debian DNS specific trust anchors to all Debian installations... (something which is IMHO more problematic). On Sat, 2014-06-21 at 16:43 +0200, Tollef Fog Heen wrote: > If they are completely untrustworthy, I'd like to see bugs with > documentation for that statement being filed so we can fix it. Take Turktrust as an example... IIRC the case correctly, they "accidentally" (whoever believes that) issued a cert which was a intermediate CA and which was used to issue forged Google certs. After days and only after long discussion they only blocked these certs... and Turktrust itself is still in (see https://bugzilla.mozilla.org/show_bug.cgi?id=826666 or some similar reports from others) even though they proved that they're either not competent enough to run a CA or they're evil. And such CAs (even though they're not big enough not to fail) are not removed, which proves: the reason to be in the Mozilla bundle (i.e. considered to be trustworthy) <-> money Same example CNNIC... governmental controlled CA from a dictatorial communist country which is known for heavy espionage against their own and foreign citizens => absolutely untrustworthy per se Any US based CA: national security letters + gag orders => absolutely untrustworthy per se Need more? ;-) Cheers, Chris.
Description: S/MIME cryptographic signature