On Mon, 2014-06-16 at 18:25 +0000, Luca Filipozzi wrote: > But I don't expect that to be anywhere close to sufficient for other distros > to > include the Debian CA (by which you probably mean the SPI CA) into their > certificate stores. I didn't mean their Mozilla/NSS cert stores, if you were talking about that.
But it should be possible for any distro (that wants to have this) to add some package where people can retrieve such keys/certs/etc. in a secure way and add it to their browsers or whatever... > I'd expect them to ask us to follow processes similar to > Mozilla's (https://wiki.mozilla.org/CA:How_to_apply). Well the main process that you need to do for being included in Mozilla is giving them some big money transfer and everything's fine then. Sure there is a pro forma policy, noone can really check whether the CAs follow these in the real life,... and Mozilla doesn't even remove CAs for which the public knows for sure that they didn't follow the policies, were to incompetent to be secure, maliciously forged certificates or are proven to be untrustworthy (just take the case around turktrust)... And that's the same for CA's like CNNIC, where one really can imagine that they're untrustworthy... > It's not clear to me > that either SPI or Debian are prepared to do that. Maybe we should go with > cacert.org... but they failed to step through the process and they're purpose > built for CA management. Na... CAcert is really not that secure... and 2 (or was it 3)? People can assert an identity... and it's not that difficult to get so many people to gether. > From my perspective, HTTPS Everywhere and Archive Security are not the same. Actually I don't really understand what was meant with HTTPS Everywhere (I rather think about it as what the plugin for Firefox from EFF having the same name does). Archive Security is for me: Only use PKI trust hierarchies which root in something that is Debian controlled (ideally having the people who actually control the key in some country which doesn't have national security letters and gag orders). GANDI in turn seems to be France based(?) but at least they have offices in the US... and GANDI itself is ultimately signed by AddTrust External CA Root, which belong to Comodo IIRC, which is - surprise - US-based... So any time any agent can send an national security letter instructing them to forge any cert used by Debian... + gag order. > I want to provide our end users, some of whom are not sufficiently technical > to > decipher SSL warnings/errors with the opportunity to have secure > communications > (to the extent that we can, anyway). Well https with X.509 has inherent problems which we won't be able to solve... But I don't think that the typical Debian user is not capable of understanding the systems/ideas behind CAs, hierarchical trust and e.g. importing CAs to their browsers. Providing security to people who don't understand security is IMHO generally a illusion... if someone wants to communicate securely, than he/she must read at least a bit into the stuff behind to understand what's actually going on, what's possible and what is not. Otherwise you have users whom you sell security but tell them to ignore that "this is untrusted" warning, download the cert (via an untrusted path), import it... and then things "are" secure. (And it's not much better if people download a Debian install image from a server that is https secured with a cert from any of the >150 CAs that Mozilla includes...) If we'd use however our own CA (which we control), then people who really care (and have the knowledge that is anyway necessary to have security) *can* have really secure communications with Debian's services. And software like apt-listbugs *can* securely communicate with the BTS... (if it only trusts that Debian CA, and not the system wide store). > I rely on the GPG web of trust for > Archive Security. If tools need to be improved, then that's where we (or > "them") should focus energies (and I seem to recall seeing an apt update, > recently). Well... agreed... but having more and more "web services" enabled,.. I have some concerns whether we introduce holes by that. E.g. if much development takes place on Alioth via git... but that git accesses are secured via GANDI https (which is ultimately under the control of our "friends" from Langley and Fort Meade),... than no one will bother to attack your GPG and rather try to break in there. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
