Ian G wrote: >> Heikki Toivonen wrote: >>> Some people have pushed for making SSL errors such that you cannot just >>> click OK and proceed to the site. I'd like to see that happen. The thing >>> that seems to be holding this back is the fear of misconfigured sites >>> becoming inaccessible. In any case, that can be done with or without EV >>> certs. > > The thing is that this is making a judgement call > that the programmer knows more than the user.
You know, in most cases the programmer *does* know better. We all know that the majority of users will just click the OK button when they see an SSL error dialog. The user simply does not know better (or is conditioned to click OK anyway). > Duane wrote: >> This might be good or bad, disabling click through might end up making >> people disable SSL altogether, ... > > Right, in which case ... there would be a reduction > in security. Security can be measured by the average > that each person gets, multiplied by the total number > of people. If a system is only enabled 1% of the > time it ain't delivering much of anything. I don't see users disabling SSL. Maybe you meant that website operators will not be serving pages over SSL because they fear this will reduce the number of people that can access their site? Although a legit concern, this hasn't seemed to bother sites that work in IE only... Besides, it would *finally* be a big incentive for the website operators to actually make sure they deploy SSL correctly. >>> I fail to find the logic in not letting me know the identity of the >>> website operators I want to do business with. > > But, that cert only makes any sense if you know the > CA that signed the cert. The blah-blah standard isn't > so much at issue; what is at issue is who signed the > cert, and what did they mean by their signature (which > might include the blah-blah standard or the whoop-de- > doo standard or the trust-me standard... ). I disagree. The users should not care who the CA is. We should have a system where the user can trust what they see regardless of the CA. It seems to me this is what EV is about. Even if we showed the CA to the user, there is no way for the normal user to find out how trustworthy the CA is. They will never hear anything about how the CA is operating. > Well, it means that the smaller CAs than Verisign > will not be able to issue EVs. Go do the maths, > the whole concept is designed to be very expensive > to implement, and if Godaddy gets 1% of its volume > from its EVs it won't be able to cover the additional > cost. Please show the math that shows this is too expensive. I don't have any experience in running a CA so I don't know where the costs come. Well, I can see travel or a use of local agent will add to expenses, and insurance (where a big CA could get a lower insurance premium), but is there anything else that would really lock the smaller players out of the picture? If you mean that it will be impossible to deal out free EV certificates I'd even have to disagree with that, because you could sell advertisements and what not to finance the certifications. > The point is that petnames cover 80% of the phishing > risk at $0 cost. EV covers 1% of the phishing risk at >>>$1k each for tops 1000 certs, and way more that > in rollout costs. The primary purpose of EV does not seem to be to prevent phishing. > LOL... My impression from reading the document > was that after 15 years of trying, the PKI field has > learnt nothing from the experiences of failure. Not > a thing, they have written this to fail, and I can't > even see how Verisign will make it work. We all seem to agree that current certificate practices are a confusing mess, and the best thing a user can rely on is domain validation. So there is obviously room for improvement. Yet the only improvement suggestion I was able to get from you was that we should show the CA's name. Anything else? -- Heikki Toivonen _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
