At 10:18 AM +0100 5/28/07, Gervase Markham wrote: >Paul Hoffman wrote: >> The current thread is about a proposal that says, in essence, "we are >> willing to accept a secret audit of a trust anchor that we cannot see >> from a national government security agency, but if we accept that, the >> trust anchor can only bind identities that contain a domain name in that >> nation's TLD; trust anchors with non-secret audits can bind any type of >> identity". To me, the first part is too much of a leap. I agree with >> others who say "no secret audits", and the corollary to that is that all >> trust anchors can bind any type of identity. > >But what is a "secret audit"? Frank makes a good point when he says that >the amount of a WebTrust audit that we can view (the audit report and >management assertions) are far from the complete contents of the audit >report.
Fully agree. >Essentially, a WebTrust audit is the auditor saying "We checked, and >they do what they say". In this case, we have a government saying the >same. The question is: is that an identical situation (in which case we >should allow these certs in unconditionally) or is it different in some >way? But one way it's not significantly different, to my mind, is the >amount that we know about the audit. In that case, then we should treat those trust roots the same as we do all others. I thought the topic of this tread was: > There are currently two CAs who have applied for inclusion in the NSS > store but their audits were done by their respective governments and are > classified, and/or they are directly controlled by those governments. If it is classified, that means we do not have access to the information in it; that's the part we are talking about. If the "controlled by the government" part is equivalent to our other audits, they should be treated equivalently to our other trust roots. > > - Without seeing the audit, we have no idea whether the security used by >> the agency would pass muster for the identities being bound. This means >> that the standards we hold VeriSign to for certificates whose identities >> are in .kr different than the standards we hold KISA to. When the user >> goes to foo.kr, they can't tell what level of security Mozilla chose for >> the certifier. > >They know that either Mozilla or the Korean Government are happy with >it. If they don't trust us, they shouldn't be using our software. If >they don't trust the Korean government, it's a bit unwise to be doing >"secure" transactions with websites in .kr. Fully agree. We already allow users to add trust roots from places that they trust. > > - There are plenty of companies in Korea that are identified by domain >> names outside of the .kr TLD. It is incredibly inconsistent for us to >> say "we trust you for identities in this TLD but not that one" when what >> little we know about their audit has absolutely nothing to do with their >> ability to discern between companies using one TLD versus another TLD. > >Our trust restriction is based on where the auditor has authority to >pronounce a set of procedures "good enough". The Korean government has >authority to do so for Korean companies. OK, now you're saying that their audit is not as good as a WebTrust audit. This is confusing. If it is as good, it doesn't matter who did it or in which country. If it isn't as good, then we agree that there should be tighter restrictions. My feeling is that the tight restriction should be "we don't include it at all". >"Companies with websites in >.kr" is (fairly closely) a strict subset of that group. Therefore, by >restricting to .kr, we are not allowing the CA to overreach the trust we >feel we can put in it. It may underreach, but that's just the way it is. Agree. I am proposing underreaching further than you. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
