(I guess we're all wearing our affiliations on our backs, but disclosure: I'm a US federal government employee, but am not speaking on behalf of the USG, and don't have any professional affiliation with the US FPKI run out of the Treasury Department.)
On Fri, May 15, 2015 at 11:49 AM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> 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 It does not presume corporations are trustworthy and governments are not. It does presume that governments are different in some way than corporations, and that that difference, in the context of the CA system and the root program, might merit name constraints. The health of the CA system, and the root program that manages it in many ways, relies on leverage, accountability, and market forces to keep it in a stable place that supports a strong internet. We all acknowledge the CA system, like the DNS system, is imperfect and not fully centralized. It's not all math -- it relies on human factors and institutional incentives. Governments are not subject to the same kind of leverage, accountability or market forces that corporations are. The legal constraints they operate under are different, your likelihood of prevailing in a legal action against them is different (and highly subject to the government in question), and their business practices and incentives are going to be very different. In other words, you cannot expect a government CA to respond to the same kinds of forces, either market pressure or deliberate browser/community pressure, that a commercial CA would. This distinguishes those kinds of CAs in a way that does *not* require to you to rest on the vague or general idea that governments are less trustworthy than corporations. Another factor is _why_ the government CA is applying to the trusted root program. If the government CA only intends to issue certs for its own properties, and its properties can reasonably be concluded to fall under a clear name jurisdiction, then name constraints don't actually "constrain" their business model. This avoids "slippery slope" concerns that might lead to constraining a commercial CA against their will. If a government CA is applying in order to provide certificates for its country's corporations or citizens, that's a more complicated issue. Treating ccTLDs (e.g. .in) as actually geographically bound, for the purpose of a CA system, seems brittle and very much something that *advances* the idea of the internet as geographically bound. By contrast, to constrain a government to its own properties (e.g. .gov.in or .gov) doesn't advance a geographic boundary, but an organizational boundary. The idea of constraining a government CA (like India or the US) to its own properties is, to my mind, very different than constraining a corporation (like Google or Microsoft) to its own properties. We, the browsers and standards bodies of the internet and the people of the earth, have very different leverage over abuses by a corporation than by a government. > (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. As described above, this is not always correct. In the case of a government asking for admittance to the root program for the intent of issuing trusted certs for its own organization, the government is not asking to "openly participate" in the first place. They are asking to participate with a closed set of domains, and name constraints can function to enforce that closed participation. Some people may also feel they are appropriate for corporate CAs who intend to issue for themselves, but that's not what I'm arguing here, nor do I feel there is risk of a slippery slope. 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. > This argument only applies to scenarios in which the public (in any country) is restricted in some way from the domains they can issue. When constraining a government CA to issue in a namespace like .gov.in, or .gov, no one's market choices are limited. In fact, such a name constraint in the root program would also *not* require that government to prevent other commercial CAs to issue certificates for a government suffix. (And, briefly offering my own work perspective, as someone who configures .gov certificates from commercial CAs, I would never desire this sort of limitation.) In short, the public's market choices are unaffected, and the government's own market choices for their own properties are only expanded. 6) The effectiveness of the Internet as a public resource depends on > interoperability (protocols, data formats, content), innovation and > decentralized participation worldwide. > That's absolutely correct. However, neither DNS nor the CA system are fully decentralized. They each depend on political tradeoffs and a careful evaluation of incentives -- the current IANA transition <https://www.newamerica.org/oti/controlling-internet-infrastructure/> is an excellent reminder of that. > - Name-constraining CAs has the effect of centralizing protocols > (vis-a-vis DNS) > I don't understand the phrasing here. The trusted root program is already a centralized repository of data that constrains who can become a CA. > - 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") > You're absolutely right that there's a judgment call involved in deciding "what is a government CA". CNNIC comes to mind as a contested example. However, in cases where there is no ambiguity about whether the CA is a government CA -- for example, a CA operated by public sector money in an internationally recognized country who describes themselves as a government and who intends to issue for other unambiguously government entities -- there's not much of a subjective judgment call involved there. 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 believe you've described the ways in which name constraints can make things worse *if* various other clearly definable things happen, such as: commercial CAs being restrained, or a cert for a ccTLD only being issuable by a particular CA, or a government CA being restrained against their will from issuing certificates for non-governmental entities. I think we can discuss name constraining government CAs without invoking these scenarios. Holistically, your argument describes a slippery slope. I don't believe slippery slope arguments are wrong, but if you can define an unambiguous rationale and line for certain behavior, I think the slippery slope argument can be clearly outweighed. 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? > You describe complicated and ambiguous situations. The best answer to this kind of ambiguity is to err on the side of No. Don't name constrain them, and if no name constraints means the root program isn't willing to accept them, then don't do it. > > 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/ ? > That's a separate issue. You're definitely correct when you point to corporate CAs not being definitionally more "trustworthy" than government CAs. It's a hostile world out there. However, I do think that if a CA *can* be clearly defined as a "government CA", and that government CA is interested in issuing for itself -- then, because an unambiguous government CA operates under fundamentally different legal and operational constraints than a commercial CA, name constraints only expand opportunity and flexibility for all parties involved. I'll also say that in my opinion, an *unconstrained* government CA whose operational mandate is only to issue for itself has a worse impact on the quality of the trust store than an unconstrained commercial CA. Name constraints seem the only appropriate way to admit a government CA to the trust store who is only supposed to be in the business of issuing for themselves. If name constraints aren't applied, I'd advocate for rejecting that CA's application. > 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. > Certificate transparency and public key pinning are fantastic technical patches to the global CA system, and the CAB BRs and audit quality are crucial human patches. Name constraints are also a patch, and they provide a function not offered by CT, PKP, BRs, or audits. When applied in a non-ambiguous, narrow way on actors who clearly differ in the accountability and leverage that human institutions can bring to bear on them, those name constraints make the CA system and root program more flexible, not more brittle. -- Eric > > _______________________________________________ > 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
