<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">If there's a non-EV CA that would give you a cert for DNS name <a href="http://amazon.com">amazon.com</a> - I'd like to make sure it's in my list and marked Not Trusted.<br><br><div id="AppleMailSignature">Regards,<div>Uri</div><div><br></div><div>Sent from my iPhone</div></div><div><br>On Dec 7, 2018, at 17:02, Kyle Hamilton <<a href="mailto:aerowolf@gmail.com">aerowolf@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">CAs *do* verify the attributes they certify.  That they're not presented as such is not the fault of the CAs, but rather of the browsers who insist on not changing or improving their UI.<div dir="auto"><br></div><div dir="auto">The thing is, if I run a website with a forum that I don't ask for money on and don't want any transactions happening on, why should I have to pay for the same level of certainty of my identity that a company like Amazon needs?</div><div dir="auto"><br></div><div dir="auto">(Why does Amazon need that much certainty? Well, I could set up wireless access points around coffee shops in December, point the DNS provided at those WAPs to my own server and run a fake <a href="http://amazon.com">amazon.com</a> site to capture account credentials and credit cards. Without EV, that's a plausible attack. Especially with SSL being not-by-default, someone could type <a href="http://amazon.com">amazon.com</a> and it can be intercepted without showing any certificate warning -- which then allows a redirect to a lookalike <a href="http://amazon.com">amazon.com</a> name that could get certified by something like LetsEncrypt.)</div><div dir="auto"><br></div><div dir="auto">Plus, clouds have had a protocol available for doing queries to certs and keys held by other parties for several years. Cloudflare developed this protocol for banks, for whom loss of control of the certificate key is a reportable event, but who also often need DDoS protection. There's no reason it can't be extended to other clouds and sites -- unless Cloudflare patented it and wants royalties, in which case their rent-seeking is destroying the security of the web by convincing cloud salesmen to say that EV is too much trouble to deal with and thus should be killed off in the marketplace.</div><div dir="auto"><br></div><div dir="auto">Demanding that EV be perfect and dropping support for it if it has any found vulnerability falls into a class of human behavior known as "letting the perfect be the enemy of the good", which is also known as "cutting off the nose to spite the face".  It still cuts down on a huge number of potential attacks, and doing away with it allows those attacks to flourish again. (Which, by the way, is what organized crime would prefer to permit.)</div><div dir="auto"><br></div><div dir="auto">-Kyle H</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu">uri@ll.mit.edu</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>    > Quoting from Peter Gutmann's "Engineering Security",<br>
>    > section "EV Certificates: PKI-me-Harder"<br>
>    ><br>
>    >      Indeed, cynics would say that this was exactly the problem that<br>
>    >      certificates and CAs were supposed to solve in the first place, and<br>
>    >      that “high-assurance” certificates are just a way of charging a<br>
>    >      second time for an existing service.<br>
>    <br>
>    Peter Gutman, for all his talents, dislikes PKI with a vengeance.<br>
>     EV is a standard for OV certificates done right.  Which involves more<br>
>    thorough identity checks, stricter rules for the CAs to follow etc.<br>
>  <br>
>     The real point of EV certificates is to separate CAs that do a good<br>
>    job from those that do a more sloppy job, without completely distrusting<br>
>    the mediocre CA operations.<br>
<br>
So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money.<br>
<br>
I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them.<br>
<br>
<br>
-- <br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users<br></a><br>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><span>-- </span><br><span>openssl-users mailing list</span><br><span>To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users">https://mta.openssl.org/mailman/listinfo/openssl-users</a></span><br></div></blockquote></body></html>