<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling <span dir="ltr"><<a href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They _could_, for sure.<br>
<br>
But "they should"?  Citation needed.  What root program(s) require this today?</blockquote><div><br></div><div>Microsoft's most recent policy update proposed adding this, but it was pointed out that CAs are not presently doing that. I think that's a reasonable statement for SHOULD, but not MUST, to borrow from RFC 2119.</div><div><br></div><div>After all, by separating out unique issuance, CAs enable their customers to improve their security stance. I should hope the position you're advocating is not that the only things worth doing are those which are required on CAs - that'd be a rather cynical take on the state of CA security.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK, so there are at least 3 groups of intermediates that issue EV certs:<br>
  1. Issue EV certs, but also issue non-EV certs.<br>
  2. Issue only EV certs, but not trusted for EV on all EV-capable browsers.<br>
  3. Issue only EV certs, and trusted for EV on all EV-capable browsers.<br>
<br>
I agree that 'any site operator would need to know what constitutes as "EV only"', so yes, there would need to be an official list of "EV only" (group 3) intermediates/pins published somewhere, and maintained. (Publication and maintenance of such a list could be largely automated by adding a page to crt.sh or some other root program aggregator service).</blockquote><div><br></div><div>I disagree, and of course, do not support that. Group 2 is wholly sufficient for the security needs of users, and avoids introducing an additional third party (browsers) into mediating that relationship. I would be happy to point out a variety of CAs who have had difficulty in having their roots or intermediates EV recognized, due to incomplete audits or documentation. Were such an "EV only" policy implemented as you've proposed, those CAs would find themselves unable to provide their services to customers. I'm sure you can appreciate why CAs should find that undesirable.</div><div><br></div><div>A cynical take would be to suggest that by defining it as Group 3, it may be an attempt by CAs to "increase" the compatibility risk of removing EV for a particular CA, thereby trying to capture more of the market. Whether or not that is the intent, that would certainly be a result, and as such, would be unquestionably unacceptable from the browser side, and thus unlikely to ever be supported. By going through Group 2, those issues are ameliorated regardless of whether or not the browser supports or recognizes the CA's EV status, and Group 2 is fully accomodated today by browsers via HPKP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Checking != Updating.<br>
<br>
Both your HPKP-based approach and my HSTS-based approach would require the site operator to regularly check that the EV intermediate they currently use is still on the group 3 list.<br>
<br>
However, your HPKP-based approach would also require the site operator to add/remove a pin every time a different EV intermediate is added/removed from the group 3 list.</blockquote><div><br></div><div>Again, my proposal has nothing to do with Group 3 in order for site operators to recognize the security benefits nominally afforded by the enhanced vetting claimed by EV. It only requires that issuing CAs make a distinction between Group 1 and Group 2, and to allow subscribers to choose to pin to Group 2. It leaves the trust relationship solely between the customer and the set of issuing CAs, and if a customer cannot trust a CA to follow its own CP/CPS, well then, what good is anything?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not at all.  I was merely looking at the current landscape and attempting to determine the path of least resistance towards a maintainable solution.</blockquote><div><br></div><div>Right, the HPKP solution can be implemented tomorrow, with the only change being on CAs that don't already distinguish from EV capable intermediates and non-EV capable intermediates. That is, quite literally, the path of least resistance :)</div></div></div></div>