There are, of course, non-browser HTTP clients that may respect HSTS, but EV 
certificates in particular are aimed at a browser audience as it is about user 
trust indicators.

EV is *not* a security boundary in browsers, however.  It is a brand awareness 
and consumer trust product. 

I am not aware of any user agents that treat EV and non-EV content as having 
different effective security principals for purposes of the Same Origin Policy. 
 So, although it is more difficult to get an EV certificate than a DV one, that 
does not provide any effective security against a MITM attacker who can obtain 
a DV certificate.  Such an attacker can always act as a partial MITM and 
provide, using a DV certificate, trojan script content in an iframe with no 
security indicators or substitute an external script in a legitimate page and 
that script will have full access to content delivered with an EV certificate.

I would posit that means a feature like LockEV has little to no practical value 
unless and until (not likely) Web user agents provide origin isolation between 
EV and non-EV content.

-Brad Hill

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Tom Ritter
> Sent: Saturday, August 11, 2012 7:43 AM
> To: Chris Palmer
> Cc: Ben Campbell; IETF WebSec WG
> Subject: Re: [websec] handling STS header field extendability
> 
> On 10 August 2012 17:52, Chris Palmer <[email protected]> wrote:
> > Please forgive my ignorance, but do LockCA and/or LockEV offer any
> > functionality that you can't already get with public key pinning as
> > currently specified? You can pin to a given CA's public key(s), and
> > you can pin to any given EV issuers' public keys.
> 
> I can't think of one for Lock CA; but LockEV could be useful for sites that 
> want
> to deploy some additional measure, but can't/don't want to
> a) commit to a CA or b) enumerate all possible EV authorities.  It should be
> ('should be', not 'is') more difficult to get a fraudulent EV certificate 
> through
> trickery or treachery than a DV certificate.
> 
> I don't think browsers differentiate between OV and DV in any meaningful
> way, but I could be wrong.
> 
> -tom
> _______________________________________________
> websec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec

Reply via email to