Gervase Markham wrote:<snip>
<snip>- CA Foo issues a bunch of duff certs to phishers - People lose money
Very little of this has happened historically because the existing CAs now in mozilla's list have been very very good at not issuing "duff" certs.
However, mozilla is now considering changing its standards for admission to mozilla's trusted CA list. I think there is substantial risk of increased "duff" certs (especially SSL certs) from this plan.
This is a serious question, and I think it's worth looking in more depth into the extent to which this might be true; otherwise some might mistake your statement as simply FUD, and I don't believe you intended it that way.
First, what's a "duff cert" in this context? A cert issued by a CA in violation of its own policies (i.e., CP and CPS)? A cert issued by a CA to someone that the CA "should have known" might use it for fraudulent purposes? A cert issued by a CA to someone who turns out to use the cert in the context of fraudulent activity (whether the CA "should have known" this or not)? These are not really the same definitions. Which one did you (and Gerv) intend?
Second, you seem to be saying that under the past and current policies for adding certs to the Mozilla default set (as implemented by Netscape and then myself) there has been minimal issuance of "duff certs" (however defined), but that under the proposed new policy the issuance of "duff certs" could be substantially increased. The implies (at least to me) that such an increase in "duff certs" would be specifically caused by adopting the new policy, to the exclusion of other factors. Am I reading you right here?
Let's consider this: The proposed new policy differs in at least three ways from prior policies, at least from the "WebTrust or equivalent" policies I've been following:
1. It adds some additional acceptable criteria to WebTrust. (This formalizes the "or equivalent" part of the current "WebTrust or equivalent" policy.)
2. It permits approval of CAs based on evaluations by independent parties who aren't official CA auditors or security test labs. (This might include us, i.e., people in the Mozilla project, if we want to take on such tasks.)
3. It puts some minimal requirements on validation procedures that CAs have to do for SSL, email, and object signing certs respectively.
Let's take these in order:
1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456 and 102 042) is not at issue, because the other criteria are substantially similar to the WebTrust criteria, and if anything go beyond the WebTrust criteria in placing some additional requirements on CAs that the WebTrust criteria do not. Do you agree with my assessment, or do you think that adding the additional criteria will significantly increase the risk that "duff certs" will be issued? If so, why?
2. Permitting "non-traditional" evaluation of CAs is certainly something that one could imagine increasing risks, if the people doing the evaluation don't do a good job. On the other hand, I suspect that if and when any such "non-traditional" evaluation does take place (e.g., like what's been proposed for CAcert.org, and perhaps for future CAs as well), that the level of public scrutiny of such evaluation will be very high (if I can judge by the controversy this has already stirred up), which will likely minimize the risk of a bad evaluation being done and approved. (Certainly I'd be hesitant to approve a CA based on a non-traditional evaluation if there were significant questions raised about it, until/unless such questions could be resolved to pretty much everybody's satisfaction.)
But this may or may not be at the root of your concern, so let me ask directly: In your opinion, would permitting such "non-traditional" evaluations contribute to the increased risk you perceive? If so, is it the only factor increasing risk? A major factor? Just a contributing factor relative to other factors (like the one I'll discuss next)?
If you do believe that permitting non-traditional evaluations would increase the risk of "duff certs" being issued, what would you recommend we do? Tighten the requirements on when we'd allow such evaluations? Or drop the idea entirely, and require that all evaluations be done by authorized auditors and test labs?
The consequence of the latter would be to keep CAcert.org out of the list permananently, or at least until they could afford a WebTrust or other audit. It would also keep other CAs out that haven't undergone WebTrust or equivalent audits; for example, I think there's a CA associated with a German university/research consortium that would be affected by this, and I think a couple of others as well.
3. Regarding requirements on CA validation of their customers, I certainly don't have any such requirements in my current "WebTrust or equivalent" policy, so in that sense the proposed new policy is more stringent than the old policy. Did Netscape have such requirements? I have no idea. However with regard to SSL certs in particular I will note that there are already CAs issuing "domain-validated" certs, e.g., the Thawte ssl123 and Go Daddy TurboSSL services, and to my knowledge such CAs are already in the default Mozilla set and usable with Firefox, etc. (There may also be other CAs like this as well, but I haven't had time to do a thorough check.) Has this resulted in significant issuance of "duff certs"? Apparently not, or I presume you would have mentioned this.
So, I ask you: In your opinion, would explicitly permitting such "domain-validated" certs (as opposed to the implicit permission we've apparently had previously) contribute to the increased risk you perceive? If so, is it the only factor increasing risk? A major factor? Just a contributing factor relative to other factors (like the issue with non-traditional evaluations)?
If you do believe that explicitly permitting domain-validated SSL certs would increase the risk of "duff certs" being issued, what would you recommend we do? Prohibit domain-validated certs, and require that CAs do more thorough identity verification of subscribers? Require that CAs do additional due diligence (over and above identity verification) to determine if subscribers might intend to use their certs for fraudulent purposes? Would you also recommend not permitting issuance of email certs based only on email account verification (i.e., not checking identity)?
The consequence of prohibiting domain-validated SSL certs is that I would reject the request that Go Daddy currently has submitted (in bug 284677) for adding new root CA certs. To be consistent we would also remove from the default cert list the existing root CA certs for Thawte, Go Daddy, and anyone else currently issuing domain-validated certs. If we want to prohibit "account-validated" email certs then we'd also have to remove root CA certs associated with those services as well. (As a side note, I don't believe that prohibiting domain-validated certs would affect CAcert.org, since IIRC they don't issue such certs; Duane or someone else, please correct me if I'm wrong about this.)
Finally, let me consider some larger issues. Forgive me if I'm missing something, but I'm getting contradictory impressions here. On the one hand I get the impression that you and others believe that historically there have been minimal problems (and hence minimal risks to users) resulting from CA practices and the selection of CAs to be included in the Mozilla default set. Now that I'm proposing this new policy I get the impression that you and others believe it will result in significant problems and significant risks to users, even though the sorts of CAs and CA practices permitted under the new policy are AFAICT basically the same sorts of CAs and CA practices that were permitted under the old policy.
(The major exception to this is the possibility of including CAs like CAcert.org based on non-traditional evaluations; but I'm not clear there whether non-traditional evaluations are the sorts of your concern or whether it's domain-validated SSL certs and other low-assurance certs.)
The only way I can personally resolve this contradiction is to conclude that it's not the policy in isolation which is at issue, it's the policy in combination with the new environment in which protecting against phishing has become a top priority. In other words, while existing policies (which in practice permitted things like domain-validated SSL certs) may have been good enough way back when, any new policy has to be more stringent in order to counter the increased threat; it's not good enough for us to just continue and formalize existing de facto practices, we have to add some more requirements over and above what has been done in the past.
Is this what you and others are arguing? If so, it's a perfectly legitimate argument to make. But if you and others want to make this argument (i.e., that policy needs to be more stringent in this new environment) then I believe it's incumbent on you and others to a) propose in some level of details what more stringent requirements we should actually impose, and b) explain how those requirements will actually reduce the risks experienced by ordinary users.
I think such a detailed justification is necessary because there are consequences to adopting more stringent policies: We're talking about eliminating (i.e., no longer accepting as valid) uses of things like domain-validated certs that are currently in use (with apparently no problems resulting), and closing off the possibility of such uses in the future. We're in essence saying that use of SSL in e-commerce and financial applications is our primary concern, that the risks associated with SSL in such applications require us to adopt as stringent a set of rules as we can, and that all other uses of SSL have to play by the same rules, whether they make sense in other contexts or not.
I know you're busy and don't have time to create such a detailed justification, but I certainly wish someone would.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
