The Mozilla Trusted Root program can and should police violations of the Mozilla Trusted Root program, and any other fraudulent *publicly trusted* certificates. That's non-controversial.
Policing violations of more general social norms -- by choosing to actively distrust non-publicly-trusted certificates -- I wonder how effective that's going to be at mitigating the threat, and how quickly a less black-and-white case will arise that will put Mozilla in a much tougher spot. Peter Bowen explained earlier how nation-state MITMs inherently violate the Baseline Requirements: > I agree 100%. MITM implies that they are not following BR, as there > is no way they can be validating domain control[1]. This should mean > that they cannot complete a BR audit without having a massive > qualification on the report. And that the only way they could argue otherwise is to say that they have practical domain control from their nation-level vantage point. That sounds like an absurd counter-argument to me, but if there's any weakness in the BRs or Mozilla policies that allows that counter-argument to be non-absurd, then proposals to make clear in the BRs or Mozilla policies that "domain control" means something global would be helpful. -- Eric On Tue, Jan 12, 2016 at 12:07 PM, Phillip Hallam-Baker < ph...@hallambaker.com> wrote: > 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 > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
