Kyle Hamilton wrote: > The end result is that anyone who chooses to spend a hundred thousand > bucks or so on a single audit can then go around selling the benefit > of their inclusion in the trust list to the highest bidder without > fear of repercussion. Which is what they've been doing. And nobody > has the balls to stand up and say "user security is more important > than user convenience". (In addition, roots have been sold to other > companies, which have not passed continuing conformance audits.)
You're correct that the way that CAs got incorporated into browsers originally had the effect of establishing an artificial scarcity, where commercial CAs already preloaded in the browsers could take advantage of their oligopolistic position to in effect "sell their slots" to others, either by having other commercial CAs pay a fee to be able to chain up to the existing roots, or by selling existing roots outright to other commercial CA operators. My position was and is that the best way to correct that situation is to eliminate the artificial scarcity by allowing more CAs to have their roots in browsers on reasonable terms. Among other things, that means applying a "cost/benefit" (security vs. inconvenience) analysis on requirements placed on new entrants, especially where such requirements are significantly more onerous that those that were applied in practice to incumbent CAs (i.e., those already in the preload list). Eddy characterizes this as a "pragmatic" approach, and I make no apologies for being pragmatic in this regard. I've consistently said that I think that security issues with respect to CAs are simply a special case of security issues in general, and should be judged accordingly, especially when it comes to evaluating threats that are mainly theoretical as opposed to threats that have been consistently exploited in the real world. That's basically what I've been trying to do in the case of WISeKey and its Blackbox product: Figure out how real any possible threats actually are, and whether they would rise to the level that would warrant denying a request for inclusion. That also includes looking at the issue of the standards we're applying to WISeKey vs. what's been applied in the past (bothe before and after we adopted our policy). Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
