Kyle Hamilton: > > > In the event of a contract (either electronic or physical), the EV > site operator has legal assurance and agreement to adhere the minimum > standards required, and has legal recourse if those requirements are > violated. The end user has legal assurance (in the form of the EV > site operator's privacy policy) and legal recourse if anyone that the > EV site operator allows to touch the data violates those terms. >
The EV operators privacy policy can be absolutely none. But what has that to do with mixed content of SSL connections to unvalidated operators when effectively I expect to be connected to an EV validated site only? If I'm connecting to an EV validated site and underneath I'm also sharing my credit card potentially with a bunch of other sites (easily possible by including JavaScript files of other providers), then the whole EV circus isn't worth the effort. I suggest to get real! Either EV stands up to the expectations or otherwise we should consider something else instead. In that respect, I want to know from Gerv how he can make sure that my credit card details stay with the site published in GREEN at the address bar and isn't leaked from within the web page to others. More than that, the site operator might fall victim himself and doesn't have to do anything on purpose...simply third party provider X is fetching those details without the knowledge of anybody... > This is in addition to the standard fiduciary requirements, which > carry criminal penalties if they're breached. > That's about the same like saying, that EV subscribers don't have to validate their domain names...should a provider use a domain name wrongfully we could lean on the legal system. > Alright, how about content distribution through something like > edgesuite? The particulars of why an EV site operator would want to > outsource some aspect or service are rather irrelevant -- valid > scenarios for needing the ability to outsource do exist, and I don't > see any reason why their hands should be shackled. Concerning your first question, my answer is that I don't care. Concerning the later part, I see in particular one very good reason why EV sites shouldn't outsource. If you can answer my question from above (to Gerv), I'll be glad to agree with you (and Gerv). > > Additional issues involved are "the cost of an EV certificate for > every host". Looking at Verisign's current > pricing suggests that this model (price > per-certificate-per-capability-per-server) hasn't changed. > What has the price to do with it? Since when has pricing become a valid argument (for not requiring EV)? You might recall my arguments back in 2006 when adoption of EV was discussed... > > Your proposal would require every individual hostname referenced by an > EV-validated site to have the extra "EV tax" paid for it. Then don't use EV certificates if you don't need it and/or can't afford it. Paypal, Google, eBay and all the others shouldn't have a problem with that... > but I can't see why > the Mozilla Foundation should under any circumstances help CAs > artificially inflate their profit margins by forcing people who want > to use EV to either reduce the services they have available to create > their site or bite the bullet and pay the extra tax just to get the > green site name. This argument is moot and not relevant. And if I recall correctly, you supported EV very much, didn't you? > > Scenario 1: EV origin, Same issuer, same Subject, EV This and everything in the Subject Alternative Extension. > > How should the chrome be presented, in each of these scenarios? Why? Same as regular certs (Non-EV). Because that's what it is (the lowest denominator in the chain). If you'd mix plain text you'd receive effectively the plain text UI (plus a broken padlock). I think the above is comparable. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto