On 21/05/15 13:56, Peter Kurrasch wrote: > Returning to your original post, Gerv....
Thank you :-) > So here is where the difference really lies between government and > commercial CAs: control. Governments and, therefore, government CAs > wield a level of control that commercial entities normally do not. They > have the power to control who is allowed access to web sites that talk > about evolution or climate change or plans for citizen uprisings. They > have the ability to send agents to your home and harrass you for > engaging in immoral acts over the internet. > > The power is genuinely immense, and since there is so much more at > stake, the security analysis must be considered differently than for > commercial CAs. Other things governments have the power to do, which are relevant: 1) Mandate that all government websites (which, these days, citizens often have no option but to use) use a particular CA, such as their own; 2) Mandate that all websites hosted in their country use a particular CA, such as their own; 3) Compel a CA within their borders to issue a certificate, and not tell anyone. 1) and 2) are reasons why commercial pressures do not apply to government CAs. 1) actually seems a reasonable thing for a government to do - and it's one big reason why we have governmental CAs in the program in the first place. 2) is, to my mind, not reasonable. 3) is sometimes given as a reason why government CAs are not all that different from commercial CAs - "if a government CA can't misissue a cert, they can just compel a CA to do it for them, so what's the difference?". But I think there are several differences: * Not all governments have the power to compel silent cert creation (some governments still have some ideas about civil liberties); * Most governments do not host a CA within their borders; * For those which do, there is sometimes a defence of severe hardship; if the CA knew its business would be blown up were the misissuance discovered, it could argue against being compelled to do so. So while it may be possible to find a jurisdiction where there is no effective difference between a government CA and a commercial CA hosted there, I would say this is not true for the large majority of jurisdictions. >> 2) "If it is different, does name-constraining government CAs make >> things better, or not?" > > One situation that is addressed by name constraints is that today it's > generally possible for any CA to issue a cert for any domain. In the > context of a security analysis that's problematic which is why name > constraints has its appeal. > > Combine that with the power of governments and add a dash of crime show > drama cliché: motive, means, opportunity. The desire--or, perhaps, > need--to institute controls gives governments the motive. The extent to > which governments own/operate/control the internet infrastructure (or > other access to web sites) and are able to issue certs provides the > means. And if any CA can issue any cert the opportunity is always there. This is a relevant point. Without even considering motive, governments, as opposed to commercial CAs, generally have both means and opportunity to do MITM attacks on their citizens. A commercial CA generally does not, although that's not entirely true, as some organizations which control significant bits of internet infrastructure are also CAs or subCAs. > So if a decision is made to require name constraints by a government CA > that would have the benefit of limiting the opportunities for bad acts. > Absent that, are there other mechanisms worth considering that would > have a beneficial impact on the motive, means, opportunity formula? One > example that comes to mind is separating cert issuance with control of > the infrastructure. I can see the superficial attractiveness of this, although I think that it would have significantly greater definitional issues than "what is a government CA?" How do you decide whether a company has enough control of infrastructure that they can't be a CA? Do you consider local or only international factors? What if they are a CA, and they grow - do you have to stop trusting them? And so on. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
