Now for MAJOR point #2. What is the definition of "assurance" ? And what is meant by "high assurance" ?
I'll apologize in advance for not addressing all your points, both in this message and your others. I have a tight time window for doing this sort of thing, and I wanted to concentrate on a couple of key points below.
Frank Hecker wrote:<sbip>
<snip>The reason for making the "high/low" distinction depending on the presence or absence of human review is that this is directly related to the cost (in time and/or money) of doing phishing attacks that direct people to SSL-protected sites.
OK, this is getting closer to a rationale of economic security. For the phisher, there is only one question, which is how much does it cost me and how much do I earn?
Agreed, which is why I think realistically any notion of "assurance" has to ultimately justify itself based on economic analysis. To expand on your comments on the threat du jour represented by phishing, pharming, etc., one presumed thing we want to prevent (as I noted) is phishers getting throwaway certs for throwaway domains, and thereby being able to more convincingly impersonate "real" ecommerce and financial sites.
(Note that I don't certainly don't think this is the only possible anti-phishing defense, or even necessarily the best one, but it certainly seems to be what people are concerned about in the whole series of discussions we've been having re "raising the bar" relative to CAs. Hence my interest in putting out a strawman proposal on how to do this, to make the discussion less abstract and more concrete.)
Here's my attempt at a quick "back of the envelope" analysis of the economics of phishing as they relate to SSL certs (not a real analysis, but a mere sketch): "How much do I earn" could be quantified as expected "revenue" per day resulting from standing up a given phishing site at a given domain, times expected lifetime of that site at that domain (e.g., before the domain or server is taken down by others or blocked by phishing blacklists or whatever). (Expected "revenue" per day is dependent on other factors, such as the type of site being impersonated, number of phishing spam emails sent out, etc., but we'll leave all that aside for now.)
"How much does it cost me" could be quantified by some formula involving the direct monetary cost of the SSL cert, related monetary costs of applying for the cert (e.g., cost of obtaining fraudulent id documents), the time required to get the cert (which equates to potential "revenue" lost from that domain that could otherwise be "earned" in the meantime), the probability of the cert application being rejected (more lost time, assuming rejection is not instant), and the probability of the phishing fraud being traced back to the actual phisher (which combined with the probability of being caught by law enforcement and convicted of something, plus the expected fines and/or jail time, equates to loss of future gains from phishing, which can then be used to calculate a net present value figure to go into the overall cost estimate). There may be other elements I haven't thought of, but these will serve as examples.
Given such a calculation, we could (at least in theory) define a "high assurance" cert for our purposes as a cert whose cost to the phisher exceeds the expected "revenue" (i.e., fraudulent gain) for the domain with which the cert is associated. Whether we could make such a cost calculation in practice is of course uncertain, but I don't think it's totally out of the question given sufficient motivation to collect the data and do the calculations.
The other thing I'll note here is that under this approach CAs could have wildly different attributes but still have the same resulting expected costs from the phisher's point of view. For example, one CA might sell cheaper certs (or even provide free certs) than another CA, but might require a week to issue a cert where the more expensive certs might require only a day. Or, in your example of the automated but arguably high assurance CA using smart cards, etc., the short time required to get a cert might be balanced by an increased likelihood of fraudulent applicants being detected and an increased risk of significant consequences arising from violations of national id laws.
The problem then is for the defender to say "how much is this cert worth?" The relying party and the cert owner both have the same question. Now, the question is *not* totally answered by "how much does it cost?" As I described above, the cost of production of the cert is only a very weak indicator of how much it is worth.
If by "cost of production" you mean marginal cost to the CA of issuing the cert (including variable costs, e.g., labor, plus amortized fixed costs) and by "how much is it worth" you mean something like my "cost to the phisher relative to expected revenue" then I'm with you, dude :-)
The best way to answer this is to ask how much the user gets when the cert is breached. Hence, what the recent European CA was doing was a step in that direction - displaying the Euro amount. In this direction, we want to say with the cert: how much do you insure me for my loss? How much does the user get when she is phished?
Is it $1000? $10,000? Or $100?
Those are hard comparable number. That number can answer "assurance" to some degree. This is about the best answer that exists.
I understand your line of thinking here. This basically leads to another definition of a "high assurance" cert: A high assurance cert is one where the relying party is insured for at least the amount of the average phishing attack (which I think you've quoted as $5,000 or so). This is an attractive approach since it introduces a party (i.e., the insurer) who's motivated to actually do the kind of cost/benefit calculations I alluded to above (at least if they want to be profitable).
However I think in practice this approach might be problematic, for a variety of reasons. First, CAs have much fewer economic incentives to care about relying parties (who aren't actually their customers) than they do about subscribers (who are the ones paying them). Second, even assuming that the cost of getting sued by relying parties is such an economic incentive, it's quite possible that lawyers for CAs would be easily able to blunt the impact of such suits, e.g., by pointing to contributory negligence on the part of the relying party and/or escape hatches for the CA. ("You didn't view the certificate details and look at the certificate policy governing the certificate?" "You didn't read the relying party agreement, particularly the limitation of liability section?" And so on.)
And as you say, there is no browser infrastructure for exposing to typical end users the gritty details of insurance amounts related to certs, and related information. So... the question becomes:
Would it be possible for us (i.e., the Mozilla project people involved with CA selection) to reasonably assign CAs into "low assurance" and "high assurance" classes, based on our assessment of the various factors mentioned above (e.g., type of threat and likely amount of loss, direct cost of cert, length and rigor of review prior to issuance, strength of identity verification, robustness of surrounding legal infrastructure and law enforcement mechanisms, and -- for that matter -- any insurance on offer)?
I suspect the answer is that we could certainly try, and we might not even do such a bad job of it. However I suspect that any such determination would be inherently subjective, since we don't have all the hard data that would be needed to plug into a formula and crank out an answer, we don't even have a real formula, and we don't have the time to create a formula and gather the data. And I thought subjectivity was what we were trying to eliminate (or at least minimize).
Not that subjectivity is such a bad thing; we rely on people's subjective judgements every day in the Mozilla project -- that's basically what module owners are trusted to do. However CA selection is one area where we don't seem to want to do that, whether rightly or wrongly.
Thus ends my time window for working on Mozilla stuff. More as I have time.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
