<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 11:27 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You got a link for that? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On <a href="https://aka.ms/rootcert" rel="noreferrer" target="_blank">https://aka.ms/rootcert</a>, the closest thing I see is...<br>
"New intermediate CA certificates under root certificates submitted for distribution by the Program must separate Server Authentication, S/MIME, Code Signing and Time Stamping uses. This means that a single intermediate issuing CA must not be used to issue both server authentication, S/MIME, and code signing certificates. A separate intermediate must be used for each use case."<br>
...which doesn't mention EV at all.</blockquote><div><br></div><div>I wasn't saying it was required, it had been proposed and discussed, as I recall. Looking through the CA/B Forum archives, <a href="https://cabforum.org/pipermail/public/2015-July/005793.html">https://cabforum.org/pipermail/public/2015-July/005793.html</a> captures some of the reaction that CAs had regarding the policy as written, which Jody later clarified (and is why <a href="http://aka.ms/rootcert">aka.ms/rootcert</a> doesn't reflect that). This was with respect to standardizing the requirement of the OIDs in the end-entity certificates, which required cutting new intermediates for CAs in order to include that OID to ensure that path processing appropriately flowed those policy OIDs down.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ah, you're right.  My mistake.<br>
<br>
Group 2 is sufficient for the HPKP-based approach.  The "EV only" intermediates do need to only issue EV certs, but those intermediates don't need to be trusted-for-EV by all browsers.  (They do of course need to be trusted-for-serverAuth by all browsers though).<br>
<br>
BTW, did your "not support that" comment also apply to the idea of adding a page to crt.sh (or some other root program aggregator service) that would automatically maintain the list of (group 2!) "EV only" intermediates?</blockquote><div><br></div><div>No, the 'not support' it was related to the idea of requiring the use of Group 3 intermediates. I would _love_ to see CAs take more proactive steps in segmenting their intermediates and documenting those policies. Just like I would _love_ to see more documentation about CAA. And I would _love_ to see more documentation about certificate profiles. In short, I love more documentation, preferably that Someone Else maintains :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A cynical take would be to suggest that by defining it as Group 3, it<br>
may be an attempt by CAs to "increase" the compatibility risk of<br>
removing EV for a particular CA, thereby trying to capture more of the<br>
market. Whether or not that is the intent, that would certainly be a<br>
result, and as such, would be unquestionably unacceptable from the<br>
browser side, and thus unlikely to ever be supported. By going through<br>
Group 2, those issues are ameliorated regardless of whether or not the<br>
browser supports or recognizes the CA's EV status, and Group 2 is fully<br>
accomodated today by browsers via HPKP.<br>
</blockquote>
<br></span>
I like a good conspiracy theory as much as the next guy, but I'm afraid in this case it was just insufficient coffee.  :-)</blockquote><div><br></div><div>=) Glad it was not intentional, but it would still have that effect, and thus is expressly undesirable. Hence my vocal and strong opposition to the premise - anything that increases the compatibility risks of responding to misissuance is... undesirable :)</div><div> </div></div><br></div></div>