> I'm confused about the role of the petname tool in a situation where a > site's private key changes -- for example, the key has passed its > useful lifetime, has been compromised and changed, etc?
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. 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. 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. iang _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
