Hi Thomas-- Thanks for the time and consideration you've put into this discussion, and for your clarifying remarks. On 03/14/2014 01:31 AM, Thomas R. Koll wrote: > 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.
I don't think the argument is quite as clear-cut. we don't even need
audits to know that groups like verisign and rapidssl have failed to
avoid mis-issuing certs, and yet we keep them in the ca-certificates
package because of the perverse incentives created by the CA ecosystem.
some of these CAs are simply "too big to fail" right now; CACert is
not, so they're getting called out for their lack of security, whereas
we simply can't afford to drop the other CAs because users would
complain about not being able to reach their favorite web sites :(
This tension results in further concentration of business among the "too
big to fail" CAs (since they're the only ones who can issue acceptable
certs, which ironically results in them being even less accountable to
relying parties in the future.
This is not a good long-term dynamic.
> 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.
This is not a good argument for including the SPI root cert, frankly.
Running debian infrastructure does mean that you can compromise my
machine by pushing out malicious software updates. but if i decide to
stop accepting software updates, or switch to some other set of apt
repositories, i'm protected against that channel going forward.
Also, it's possible for me to verify that the software updates i'm
seeing are the same as the software updates that other people on the
'net are seeing (most cheaply, i can approximate this by regularly
varying my choice of apt mirror); this makes an attack on me via
software updates much more easily detectable, and makes it more
difficult for someone in charge of debian infrastructure to target me
directly.
With SPI's root cert, stopping software updates or varying my choice of
debian mirror does *not* defend me against malicious use of the CA, and
an attack can be much more narrowly tailored and hard to detect.
Really, this is a lot of pressure on the operators of the SPI CA, and we
have very little oversight on its practice. I like and respect the
operators of the SPI CA, but this is not a responsibility i would
necessarily want to have on my own shoulders; if i was in their
position, i would actively prefer that the infrastructure i manage be
publicly monitored so that other people could alert me (and other
relying parties) if it gets broken. at the moment, i don't think such
monitoring exists.
> 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.
except for the ones that we rely on mozilla for, and mozilla themselves
are forced to carry the "too big to fail" CAs or else users will switch
to Chrome or IE.
> PS: Lastly, this is not an opinion poll. If your only contrib is a +/-1,
> close your mail programm.
This last remark seems unnecessarily rude. One of the ways that the CA
ecosystem develops (and that debian knows what to care about) is by
people being vocal about what they want and who they are willing to rely
on. This is how the large CAs stay in their position currently --
people complain if we turn them off because they can't get to their
favorite web sites. Why should we deny that particular channel of
recourse to the folks who prefer to rely on community organizations? If
someone agrees with a point that they think isn't being listened to,
then indicating agreement is a valuable contribution.
Axel, it occurs to me that one thing the CACert folks could do is to
ship a new package in debian that Depends: (and maybe Enhances:)
ca-certificates, which just ships the CACert root cert in the common and
runs the appropriate scripts in postinst; that would be roughly
equivalent to "off by default" and would still provide the
cryptographically-strong channel to fetch the CACert root cert itself.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
