On 4/22/05, Ian Grigg <[EMAIL PROTECTED]> wrote: > > If that's what has happened, then the core identity > of the merchant has in some sense changed, and then > we should expect some stuff to happen. In fact, it > is quite critical that we do surface this change of > key event as that is one of the weaknesses in the > infrastructure: a phisher can go to any other CA > and trick them into giving out a cert in the name > of the targetted merchant. The only serious way > to defend against this is to have the browser cache > the cert relationship, then ask the user to examine > the cert, and hope that the difference is enough > to inspire caution. Without that defence, PKI has > a hole we could drive a ship full of trucks through.
If it's assured by the same CA, is that Good Enough[tm]? The 'core identity' -- the first-order data that we use to determine the site's identity -- is the encryption key. However, encryption keys also have lifetimes, and life-cycles. So, we use certificates from CAs as our only proof that the encryption key is in actuality bound to the identity of the owner of the server. > Also, it turns out there is a much bigger case where > key changes are prevalent, and that is in the use of > hardware SSL farms. Larger merchants use lots of > certs in hardware, and switch rapidly between them > depending on the moment. That's not too surprising -- up until recently, no CA would issue wildcard certs, based on the concept that it would require the private key to be in more than one place, which is "bad key-handling practice". An SSL server can only handle so many SSL connections at a time, and that number is at least 2 orders of magnitude less than the number of non-SSL connections. This scheme breaks SSL session caching, though. So they're throwing money and hardware at a problem that could be solved with fewer resources, if they had intelligence in their process. > In this case, both the trustbar and petname toolbars > have developed strategies to deal with this. For the > former, trustbar suggests that you click-to-accept > *all* certs from that CA. For petname, I think Tyler > outlined his approach. Either way, there is some > experimentation to be done, we shouldn't see these > as being the ultimate word but rather steps in the > right direction of stopping the above truck-liner > being driven by phishers, as well as addressing > phishing as it is driven at the single truck level, > today. This brings to mind a question that I have: Is Firefox the best place to experiment with issues of this gravity? I agree that the status quo is broken; however, many people rely on Firefox and don't really want to play around with experimental code. Is there a development tree available for experimentation, akin to the odd-numbered variants of Linux and Apache? Cordially, Kyle Hamilton _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
