On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 12/01/2016 16:49, Phillip Hallam-Baker wrote: >> >> It really isn't a good idea for Mozilla to try to mitigate the >> security concerns of people living in a police state. The cost of >> doing so is you will set precedents that others demand be respected. >> >> Yes providing crypto with a hole in it will be better than no crypto >> at all for the people who don't have access to full strength crypto. >> But if you go that route only crypto with a hole will be available. >> > > No one (except the MiTM CA itself, possibly) is suggesting that Mozilla > include or authorize any MiTM CA to work in its browsers (or anything else > using the Mozilla CA list). > > The discussion is how to *not* authorize it, without thereby causing too > much collateral damage.
Yes, that is the issue we should be considering. The issue of collateral damage isn't just limited to one set of governments though. Anything we allow a police state, the FBI will demand and of course, vice versa which is one of the reasons for rejecting the FBI demands. > Questions being seriously discussed: > > - Should Mozilla add specific mechanisms that prevent the subjects of a > police state from obeying police orders to compromise their own > browser? This is the most hotly debated topic in this thread. > > - Should Mozilla find a mechanism to allow only the non-MiTM part of a > dual use CA which is being used both as an MiTM CA and as the > legitimate CA for accessing government services, such as transit visa > applications by foreign travelers planning to cross the territory of > the police state on their way somewhere else? > > - How to most easily reject requests by the MiTM CAs to become > globally trusted CAs in the Mozilla CA store. Without causing > precedents that would hurt legitimate CAs from countries that happen > not to be allies of the USA. So far, the best suggestion (other than > to stall them on technicalities) is to find an interpretation of the > existing CA rules which cannot be satisfied by any MiTM CA. Not accepting a demand, making clear a demand will never be accepted is not the same as giving a refusal. On the other questions, let us return to what the original basis for the WebPKI was: Process. There are existing precedents for revoking certificates that are demonstrated to be malicious. One of the purposes of the CAA extension was to provide an objective definition of malicious behavior. There are at least two parties that have infrastructure that is capable of detecting certificates that violate CAA constraints. At the moment we don't have a very large number of domains with CAA records. The more domain name holders we can persuade to deploy CAA, the sooner an objective default will be detected. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
