At 6:06 PM +0100 5/24/07, Gervase Markham wrote: >Paul Hoffman wrote: > > That makes the assumption that all domains from those countries are in >> the countries' TLDs; that is a bad assumption. > >You mean that these CAs will not be able to sign certificates for some >sites that they might want to (e.g. www.myfrenchsite.com)? Yes, but >that's just tough on them.
My feeling is that we would be better off not making this leap of limitation. Either someone is allowed to certify in all domain names, or in none. I worry that we are opening ourselves to some tricky politics. For example, what if the government of China insisted that Mozilla not allow VeriSign to certify for names in .cn? Don't laugh, they at one point demanded that VeriSign not allow IDN domain names in Chinese in .com. More salient and worrisome, what if we allow in a CA run by the government of Iran, and the USGovt demanded that Mozilla not allow them to issue certs for names in the .us TLD? The easiest way to avoid such problems is to not get into the business of subsetting which domains a CA is allowed to use in the identifiers. > > I propose that we simply do not allow classified audits. Those two CAs >> can get additional, non-classified audits if they want to be in the root >> store. > >That's certainly the alternative. However, I believe at least the French >argued that they couldn't get a commercial audit for some reason or >another. But my memory may be misleading me. Even if true, I think saying "that's just tough on them" in this case is a better policy for Mozilla than to do subsetting based on TLDs and say "that's just tough on them" for the subset. From a security perspective, having a "classified" audit (that is, one you can't read) is much worse than us trying to guess which TLDs someone is able to use in identifiers. > > If FubarSign came to us with a "classified" audit from a commercial >> auditor, would we even consider it? > >No. > > > Why should countries be different than commercial entities? > >Because they have jurisdiction over their citizens, and (in direct or >indirect ways) over their TLD. KISA has as much jurisdiction over Korean citizens as NIST has over US citizens: nearly none. >If the Austrian Government CA comes and >says "We have ten million Austrian citizens using our email certs; >please add our root to Thunderbird", who would we ask to audit them? Yes >A >better solution, surely, is to add it but allow them to sign only .at >addresses. We disagree here. I feel that a better solution is to treat them like all other CAs from a trust and security perspective. BTW, thank you for bringing up that example. It opens up a great can of worms: -If the Austrians get their un-audited root cert in the Mozilla store for user identity certs, how do we know that they are only issuing them to Austrian citizens? Would we even restrict them to that? What about dual citizenship people? -If the Austrian government says "we designate this commercial entity to issue email certs", do we treat that CA under the government rules or the commercial rules? -If we go down the path of restricting by TLD, we certainly need to have the same restrictions in the email address as we do in the domain name. Will the extensions being added handle this? At 12:19 PM +0100 5/25/07, Gervase Markham wrote: >Frank Hecker wrote: > > So the question is, if a government CA provided a statement roughly >> equivalent to the (public) WebTrust report, would that ... >...snip... > > general level of confidence in the organization doing the evaluation as >> we would with a typical WebTrust-authorized auditor. > >So, to summarise, we need: > >A) An audit to an approved standard, listed in policy section 8 >B) Performed by a competent and independent body in which we have > confidence, with criteria listed in policy section 9 and 10 >C) Which makes a public statement to that effect > >? > >And there is no reason that the body in B) should not be a government or >government-appointed, as long as we continue to have confidence in them. >We are allowed to refuse any CA for any reason under policy section 4. > >OK, I can buy that. I can buy that with you. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
