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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature