Frank Hecker wrote: > Nelson B wrote: > > 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.
> 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." I think folks learned that the US Government wouldn't allow unrestricted use of 128-bit encryption but didn't care about restricting 40-bit. Upon learning this they interpreted it to mean that the US saw a practical cryptographic difference between the two such that it didn't want to allow Netscape and Microsoft to enable trivial impediment of US government access to data. By the way, you may recall that exceptions were made for health and financial industries such that a US bank could get a special certificate that temporarily enabled "strong crypto" in "export grade" browsers during banking or medical industry service access; interesting restrictions were put in place as well such as no service to the 'bad countries' (known terrorist countries) and 'bad companies' (those known to have 'sold out' US national security interests in the past). The browser companies probably felt obliged to enable the user to make the distinction even though the service providers where enabled as well. > 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". Can I correctly infer that you don't feel any safer submitting your social security number to a site using a VeriSign Class 3 certificate relative to a 'domain-control' only certificate? > 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. I'd say that in the early days the US lawyers working in industry (legal and CA believed that such a distinction was paramount for a robust PKI. Some research will bare this out if you're really curious. This is still true today; look at the discussions the American Bar Association or the National Association of Notaries for current data; OASIS carries technical forums that are active on this topic including participation of ABA. > 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. I'm sure some CAs work very hard to ensure that their process is hard to spoof and further work at refining the process in response to changes in the landscape, including testing the authentication staff by regularly injecting fake enrollments to ensure they are paying attention. This is similar to how a responsible software provider improves their products and tests the code and UI that comes out of development. Just as one distinguishes in quality between different software providers, so it is possible to do for CA authentication practices. Do you really believe that it is as easy to get an 'identity cert' as it is to get a 'domain control' cert? _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
