On Sat, May 16, 2015 4:45 pm, Eric Mill wrote: > 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.
Just to be explicit here - you're defining government CAs not as CAs operated by a government, but CAs that tailor exclusively to a government. That is, the "why" is just a definitional short-hand for how to declare something as government vs non-government. In the cases where the CA is already restricted in its name issuance (e.g. "Government of Japan" claims to only issue for .go.jp domains, HARICA is already name constrained, etc), there is nothing intrinsically wrong or objectionable with encoding that in code. However, I don't think that's the thrust of Gerv's message, because Mozilla's happily been doing it for some time already. It's a question of whether it's right to *require* such constraints, and when and how to determine what those constraints are. So that we can discuss concrete matters, rather than hypotheticals (which, while useful, I think idealize things a bit too much) CATCert - Issues to individuals and corporations, not just public sector. ANSSI/DCSSI - Applies to government *and* administrative organizations of France. No explicit name constraint in their administrative policies is documented, although has been unilaterally imposed by browsers as a result of misissuance. Certizen - Applies not just to e-governence but also e-commerce organizations in Asia (not just HK) Government of Japan - Two roots (GPKI, LGPKI), only one included (GPKI) because they failed to respond in a timely manner w/r/t LGPKI questions. The GPKI root is "mostly" .go.jp, except evena t time of application, they had non-.go.jp names ( https://groups.google.com/d/msg/mozilla.dev.security.policy/XHaBWlrfIjk/ZtRW6ioT9CMJ ). The policies themselves don't constraint them to .go.jp, AFAICT Government of Spain (ACCV) - Operates as a public CA that caters to the citizens (e.g. how identity validation is performed) *and* local corporations. GRCA / Chungwa Telecom - Can't find any English version of their CP/CPS. Their CP/CPS repository links to a revoked WebTrust seal (although they do have a newer one), they lack a BR audit, etc. I haven't dug into the Mozilla Salesforce to see actual details. From their original inclusion request, and from the GRCA documentation, however, they're not exclusively government sites. PKIoverheid - Effectively a bridge CA (e.g. what Mozilla has so far rejected from other countries, such as the US Government or that of Brazil). PKIoverheid sets up the requirements for secondary CSPs, which it then certifies and cross-signs. Per their CSP, they cater both to government and businesses, and serve a Dutch community but not a Dutch namespace. Kamu SM - Similar to ACCV, GRCA, Certizen; no explicit government-only scope HARICA - Already self-constrained CNNIC - 'nuff said. So looking in that above list - the list Gerv proposed as those that may fit one or more definitions of "government CA", there is only one that is exclusively tied to a domain namespace (HARICA), and one "almost" constrained to a domain namespace (Government of Japan). The rest are all operated by government, but apply to individuals and corporations and not just public sector. > 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. As the above list shows, this is by far and away the dominant reason. If you further read the CP/CPSes/inclusion bugs (which I went through before replying to this message), you will find that the primary justification for why the government CA even exists is because the government wants to set its standards for identity validation according to local customs, mores, and laws. This is important later on in this message. > 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. As described above, you can see this is not the case in general, especially not the case for the CAs that people are concerned about today. > 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.) You may not desire it, but as I described above, it's already the desire of many of these governments' operating their CAs for precisely that. Indeed, if you take the broader look at the policies of the governments behind such CAs, you will often find that corporations will be enjoined to use the chosen government CA (such as when it's a meta-CA, as with PKIoverheid) or to use a CA that participates in the governments' certification program. Indeed, this is precisely why audit criteria like ETSI exist! Take a look at India (required if handling taxpayer info to use an appropriately certified CA) or Turkey (a roughly similar story). That is, these government CAs exist not just to offer specialized services for their citizenry, they exist to support the e-signature/e-commerce regulations of the appropriate nationstates. The logical implication of this is that if you can imagine a definition where we say government CAs (those either operated directly by or under the supervision of) a given state, like say India, would be constrained to a namespace, such as .in, then *we're* (trust store maintainers, the community at large) saying that commercial organizations that which to perform those actions in India MUST use a .in domain (since they can't get a cert from one of the CAs unless they do). And thus, naturally, have even greater risk of interference by India (not to pick on India, it's just a more familiar example a result of investigating India CCA) I'm not concerned about such constraint policies *requiring* governments from peventing other commercial CAs. They already do that. I'm worried about it *enabling* even greater restrictions on an open Internet and that governments' citizenry. > 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. Look through the examples Gerv noted, and you will see that while this is a theoretical possibility for such entities, it is the exception, not the rule, and thus doesn't answer the core question. > 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, Already happening > or a cert for a ccTLD only being issuable > by a particular CA, Already possible today > or a government CA being restrained against their will > from issuing certificates for non-governmental entities. The natural implication for the CAs initially suggested as "government CAs" > I think we can > discuss name constraining government CAs without invoking these scenarios. As you can see above, they're all very real *today*, so I don't think we can, nor do I think we should, since we have amble evidence about the existing nuance in the system that we cannot ignore and must account for. > 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. I understand and agree with you here - but I don't believe that's what is under discussion here, because that definition has long been functioning within Mozilla. I say this because knowing Gerv, and having participated with him on the call, I suspect that in part this is motivated by https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft has suggested they'll require "government CAs" (definition not provided) to be constrained (how not provided). The details of which are only available under NDA with Microsoft. Of course, that creates a variety of problems for public debate around the issues, hence this thread here, which has also been renewed by other discussions of constraining (or rejecting) government CAs in other fora. So while I agree that a self-constrained (by law) government CA that wishes technical constraints (or discloses their constraint) is a non-issue for adding constraints, we do need to have the broader discussion of "operated on or behalf of a government" and the implications there, which are almost certainly unilaterally imposed rather than self-imposed. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
