Everything that Ryan says below, is what I would have said if I were as eloquent.
- Matt On Fri, May 15, 2015 at 11:49:39AM -0700, Ryan Sleevi wrote: > On Fri, May 15, 2015 1:52 am, Gervase Markham wrote: > > On 15/05/15 00:01, Ryan Sleevi wrote: > > > I think there's also the broader consideration of whether Mozilla's > > > policy > > > interests are served by promoting borders on the Internet, which David's > > > proposal certainly does, but the broader question invariably does. > > > https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all > > > seem relevant to the broader discussion of the implications of such a > > > policy. > > > > It would be helpful if you could expand upon this point, and the > > relationship you see between those three principles and the proposal. > > 2) The Internet is a global public resource that must remain open and > accessible. > > - By introducing a demarcation of power/privilege by "government" or not > (which still suffers from the definitional issue that you've entirely > danced around :P), it ostensibly undermines the notion of global (e.g. if > you're required, by local jurisdiction, to only use CAs approved by > Country A, then you can no longer apply for any arbitrary name but only > those CAs approved by Country A can issue to) > > - By introduction restrictions on what government CAs can do, it creates a > different standard of openness. That is, it presumes corporations are > trustworthy and governments are not (this is your first question, which is > implicitly answered in the positive in any discussion pro-constraint), and > corporations can openly participate while governments cannot. > > 4) Individuals' security and privacy on the Internet are fundamental and > must not be treated as optional. > > - In the pro-constraint case, which again arguably answers the first > question you pose by saying "Yes, there is a difference", it introduces > the beginnings of technical control to introduce borders on the Internet, > by (effectively) restricting what domains individuals can purchase, and > further encouraging a centralization of names that are in government > control. Using my previous message as an example, I may choose to purchase > resources from China and the US under the assumption that they will not > mutually aid eachother in compromising me, even if they may both > independently attempt to. > > 6) The effectiveness of the Internet as a public resource depends on > interoperability (protocols, data formats, content), innovation and > decentralized participation worldwide. > > - Name-constraining CAs has the effect of centralizing protocols > (vis-a-vis DNS) > > - Name-constraining CAs has the effect of discouraging interoperability by > introducing multiple semi-subjective criteria into the discussion of trust > ("What is a Government CA", "What is a government TLD") > > > > In case it's not clear, I think imposing name-constraints on CAs to be > > > bad > > > for the web and not a scalable solution, even if it appears attractive > > > :) > > > > Again, expansion on these points would be appreciated :-) > > I'm sure just as you wish for me to expand on this, I wish to understand > what specifically you're asking about. > > This conversation has been raised multiple times, and I've raised multiple > objections and concerns each time it's been raised. For better or for > worse, I've written fairly extensively on this list why it's a bad idea, > and why various proposed modifications are equally problematic. > > I've at length answered your first question posed - which is whether there > is a fundamental difference - and pointed out the myriad of ways in which > there is not. > > I've at length answered your second question posted - which is whether it > makes things better or worse - and demonstrated the many ways in which it > can make things worse. > > I mean, the definitional issues alone should show how subjective this is. > For example, I note you didn't include under "potential government CAs" as > LuxTrust ("Established in November 2005 through a partnership between the > Luxembourg government and major private financial actors in Luxembourg"), > or what the subtle implications are for Certinomis (which partners with La > Poste to perform identity validation, which is the mail service of France, > is definitionally an autonomous public enterprise since 1 January 1991, > when it was split from DGP, but which arguably operates within the > imprimatur of the French government) > > I posit these as simply two examples of many to indicate the very > difficult challenges with separating 'operational capability'. However, > would we argue that a CA is wholly independent if it was seeded by > In-Q-Tel? Why or why not? > > What about a CA operated by Verizon Business (aka GTE Cybertrust/Baltimore > Cybertrust?) Some are concerned that it may be participating in NSA > shenanigans (e.g. > http://rt.com/usa/168752-germany-boots-verizon-over-spying/ )? Or what > about several major US telecom providers' complicity in the NSA's > warrantless wiretapping - > http://www.wired.com/2010/01/fbi-att-verizon-violated-wiretapping-laws/ ? > > There are so many more important things to spend our time on with regards > to improving trust. Simply embracing and encouraging greater transparency > (e.g. through Certificate Transparency) could go a long way in > establishing an objective basis for discussions about trustworthiness, and > the quality of audits, and the compliance and adherence to technical > requirements, rather than gut speculation and the jingoistic > sentimentality it inevitably invites. > > -- > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- "Riding through the tunnel at 200 is something you should approach in the same way you'd bonk your neighbours wife. A once in a while thing. Do it often and you'll get caught." -- Kel, aus.moto _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
