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

Reply via email to