Banks told their users "40 bits isn't good enough", and "we won't let you do online banking with us with a browser that can only do 40 bit crypto". The users didn't know 40-bit crypto from Limburger, but they got the message that it their browser could only show one tooth, it wasn't good enough for banking.
I'm actually not disagreeing with you, but there are some important points here that I want to highlight because IMO they're relevant to the present discussion. I'll warn you and others in advance that some of my arguments may seem philosophical in nature, but I do think that the philosophizing has a valid purpose.
First, we have to distinguish between differences in technical mechanisms and the meaning that people attach to those differences. (By "people" I mean typical users, but often others as well -- including us.)
To repeat: From a technical point of view the "one tooth"/"two teeth" UI difference (one for 40-bit, two for 128-bit) was simply a distinction regarding key length that arose from external factors (i.e., US encryption export regulations). No one deliberately sat down and said "We'll design SSL to have a 'good enough for banking' mode and a 'not good enough for banking' mode, and we'll choose 128-bit encryption for the one and 40-bit for the other."
On the other hand, once the technical distinction existed banks then attached a particular meaning to the distinction: that secure on-line banking required 128-bit keys, and could not be done with 40-bit keys. And why should they not do so? Certainly all other things being equal, using 128-bit encryption was at least as secure as using 40-bit and possibly more so. (Or to put it in risk terms, using 128-bit certainly did not increase risk vs. using 40-bit, and might possibly decrease it.) And for US banks there was little or no cost in mandating use of 128-bit encryption, so why not do so? (The only real impact would have been for US banks with non-US customers, a fairly small group.)
(Note to Ian: Whether 40-bit encryption actually posed a real security risk or not is IMO irrelevant to the banks' decision making. Arguably not allowing use of 40-bit for online banking was irrational in some sense, but I believe that in real-world security decisions irrationality can't be removed from the equation, no more than it can in real-world economic decisions -- e.g., behavioral economics -- and has to be accounted for in any analysis.)
Once the banks attached meaning to 40-bit vs. 128-bit then clearly end users picked up on that meaning (to the extent that they associated any meaning at all to the 40-bit vs. 128-bit distinction). By the time the liberalization of US export regulations ended the need for 40-bit, the equation "(128-bit) SSL means 'secure for banking'" was firmly fixed in people's minds, as it remains today.
Now, what does this have to do with the present discussion? Simply this: we are again dealing with technical distinctions first and foremost, and then running into trouble trying to attach firm fixed meanings to those distinctions. More specifically: On the one hand we have certificates (specifically SSL certs) that are issued after a particular type of CA process, a process (typically automated) that verifies the suscriber's control of the domain associated with the cert. On the other hand, we have SSL certificates for which the CA's processes also include additional checks (some automated, some not) through which the CA purports to verify the claimed real-world identity of the subscriber.
At heart this is a technical distinction that IMO is ultimately driven by the economics of the CA business: (commercial) CAs are motivated to reach a new class of more price-sensitive customers (because their traditional business has reached a plateau) and reaching those price-sensitive customers requires achieving cost efficiencies, which in turn can be done through the introduction of increased automation and taking humans out of the loop.
It's tempting to attach a meaning to this technical distinction between "control of domain" certs and "claimed identity" certs, and say that the first is "low assurance" and the second is "high assurance"; the CAs themselves encourage us to attach this meaning, just as the banks encouraged us to think of 128-bit SSL as "good enough for banking" and 40-bit as "not good enough". And the organizations running e-commerce and online financial sites have no reason to object to CAs attaching the "low" / "high" labels; after all, from the point of view of those organizations the difference in cost between "control of domain" and "claimed identity" certs is negligible, and so they might as well choose the (claimed) "high assurance" option. However I think we should resist attaching the "low assurance/high assurance" meaning to this distinction, at least temporarily -- while I finish my argument! -- and maybe permanently, for the following reasons:
First, as with 40-bit vs. 128-bit I think the "control of domain" / "claimed identity" distinction arises from external factors not necessarily intrinsic to the actual security issues. Again, I doubt that anyone did a thorough security analysis and concluded from that analysis that we absolutely needed two (or more) types of certs and associated cert issuance processes. IMO it's more that the distinction between different types of certs *could* be made on technical grounds (having to do with different cert issuance processes) and having done that it's then tempting to attach fixed security-related meanings (e.g., "low/high assurance") to the distinction.
Second: If we restrict our discussion to a given CA and don't care about cost, it's certainly preferable to have a "claimed identity" cert than a "control of domain" cert, since within a given CA a "claimed identity" cert application involves all the checks done for a "control of domain" cert plus some additional checks as well, and the manner in which the checks common to both types of certs are done is the same. As a result the "level of assurance" for a "claimed identity" cert is certainly not less than that for a "control of domain" cert, and could possibly be greater. However once we consider the domain of all CAs then we can't necessarily assume a priori that this will remain true.
(Similarly in the 40-bit vs. 128-bit case the equation 'security of
128-bit' >= 'security of 40-bit' wasn't necessarily universally true
across all browsers and web servers; for example, the security of
128-bit encryption in Netscape Navigator 1.0 was less than the security
of 40-bit encryption in Netscape Navigator 2.0, due to SSL implementation flaws in NN 1.0.)
Thus we can't necessarily throw all "control of domain" certs into a "low assurance" category and all "claimed identity" certs into a "high assurance" category, with any cert in the "high assurance" category being associated with less risk than any cert in the "low assurance" category. (This may have been one of the points Ian was trying to make with his questions asking why one CA sold a "high-assurance" cert for less than another CA sold a "low assurance" cert.)
Finally, it's not clear how big the "assurance gap" really is between "control of domain" certs and "claimed identity" certs, and whether it's large enough to justify using terms like "low" vs. "high" to describe the two types. Clearly if it were trivially easy and cost nothing at all (in terms of time, money, whatever) to "spoof" a CA's identity verification process (i.e., to get a "claimed identity" cert under a false identity) then there wouldn't be enough difference to justify a "high/low" distinction. CAs will protest that it's not trivially easy to spoof their procedures, and I'll gladly give them the benefit of the doubt, but IMO using words like "low" and "high" in this context is still something that can't simply be assumed a priori to be appropriate.
At this point you may be saying, "Enough philosophizing already, what's your point?" My purpose in doing this is to try to think through my strawman UI proposal earlier (to replace the binary "no SSL"/"SSL" UI with a more multivalued model) and to try to improve it and address some of the objections to it.
In particular, one of the main objections to the strawman proposal is to the division of CA certs into "high assurance" certs (for which the padlock is displayed) and "low assurance" certs (for which something else is displayed), on the grounds that such a division isn't actually valid or straightforward to do. I think those objections are worthy of a serious response, and any realistic proposal has to take them into account.
As I mentioned in previous posts, the Mozilla Foundation could certainly take on the task of deciding which CAs and certs were "high assurance" and which were not. The problem is that IMO it's difficult to do this in a way that is simultaneously easy, objective, and correct (i.e., reflecting the real risks -- not simply the hypothesized risks -- as determined by a rigorous security analysis).
So what's the alternative? One alternative is to retain the division of CAs and certs into two (or more) classes for purposes of the UI, but not go overboard in presenting this as a "low" vs. "high" distinction. For example, we could make a UI distinction between "control of domain" SSL certs and "claimed identity" certs, but in presenting this to the user (e.g., in informational messages and the like) we would simply present the technical distinction and not editorialize about "trust", "high assurance", "safe for online banking", and the like.
(So, for example, when a user is presented information about an SSL-enabled site with a "control of domain" cert issued by the Foo Class 1 CA, Firefox might display something like "The site you connected to has the domain name 'www.acmewidgets.com', as verified by the 'Foo Class 1 CA' independent service", while for "claimed identity" certs Firefox might display something like "The site you connected to has the domain name 'www.acmewidgets.com' and is operated by 'Acme Widgets, Inc.', as verified by the 'Foo Class 1 CA' independent service.")
Now, would users and others insist on attaching meaning to the UI differences, i.e., that seeing the padlock means "safe for e-commerce/banking" and seeing the checkmark means "not safe enough"? Of course they would; this is inevitable given that (at least some) users already existing expectations, and that CAs and operators of major e-commerce and financial sites have an interest in promoting and reinforcing those expectations. But we as browser vendors don't have to join them in doing this, and arguably it would be better if we didn't.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
