<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 10, 2017 at 10:36 AM, Rob Stradling via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not all CAs have chosen to use separate intermediate(s) to issue only EV certs.<br>
<br>
e.g., <a href="https://crt.sh/?Identity=%25&iCAID=904" rel="noreferrer" target="_blank">https://crt.sh/?Identity=%25&i<wbr>CAID=904</a></blockquote><div><br></div><div>I didn't say they have - I said they should.</div><div><br></div><div>Any CA who isn't using a distinct EV intermediate can, in the future, do so for new certifictes, w/o any issue. That's not a hard blocker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Whereas adding an "EV only" option to HSTS would...<br>
<br>
1) avoid the need to coordinate and maintain a list of "EV only" pins.<br></blockquote><div><br></div><div>That's not correct. It just outsources the problem back to the user and the browsers - any site operator would need to know what constitutes as "EV only". For example, if browsers don't all update their EV list on the exact same day (and they don't), then you end up in a situation where Browser A recognizes a site as EV-only and Browser B does not. The implications of this are that the site would break in Browser B (if the pin was noted).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) avoid the need for site operators to update their local copies of the list of "EV only" pins.<br></blockquote><div><br></div><div>It doesn't. A site operator would constantly have to be checking what sets of CAs the browser noted were for EV only, to make sure their CA was providing that.</div><div><br></div><div>It's riskier for browsers to do so, because now there's zero relationship with the customer (the site operator) and with the CA (to make sure their PKI hierarchy is sane). As plenty of CAs in the Forum can attest to, they have been bitten where cross-signs of their intermediates lead to incorrect recognition of EV status. Or browser bugs related to certificate policies.</div><div><br></div><div>This instead promotes a direct relationship between the customer and the CA, which is the only relationship for which a reliable means of communication exists (quite literally, in the case of EV!)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) work even in the case of a CA that hasn't chosen to use "EV only" intermediate(s).</blockquote><div><br></div><div>Sounds like you're saying CAs are incapable of change? ;) </div><div><br></div><div>More pragmatically, nothing about the proposed solution is blocked on any new development, other than the CA needing to do something if the CA wants to offer this service to its subscriber. That's quite literally the exact place the cost of work should be borne. A CA can dedicate one or more intermediates to EV and begin issuing _today_ (provided they've got their ceremonies scripted and ready).</div></div></div></div>