<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 1:27 PM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For me, one outcome of the previous discussion was that it’d be a lot easier if browsers could require serverAuth in EKU.  The number of remaining unexpired certificates without serverAuth is now very small; the only thing preventing me from saying we should all switch to it ASAP is that the SHA-1 and RC4 deprecations are in the pipeline, are more important, and there are limited resources.<br>
<br>
Once that’s done, I think there’s a strong case for saying that anyone who wants an certificate with anyEKU must comply with all the requirements for each kind of certificate; if there are contradictions then those need to be worked out.</blockquote></div><br></div><div class="gmail_extra">As much as I would like to think that's reasonable, it has two very detrimental side-effects:</div><div class="gmail_extra">- It doesn't cover the case of intermediates, which can then cause issuance of serverAuth EKUs. In practice, I think those are far more concerning and important to encourage disclosure of.</div><div class="gmail_extra">- It only serves to protect the bleeding edge of users. Historically, the changes that the CA/B Forum have adopted have applied ecosystem wide - which is generally a strength, but understandably causes some concerns with some deprecations (e.g. SHA-1). I can say at Google we're very concerned not just for what users using the bleeding edge of (Chrome, Android, ChromeOS) see, but also those on the long-tail. While the Chrome and ChromeOS long tail is rather short, Android is... unfortunately long. So we try to look for improvements that affect the entire ecosystem.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thinking more holistically at the Internet community, such a change really doesn't help users using other HTTPS-validation libraries (that is, they're not user agents, but they're accessing the same resources using the same technologies). Think of PHP, Perl, Python, Ruby, Curl, Wget, etc. Those are all TLS certificates used for server authentication of domain names, but which may validate things slightly differently.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That's not to say we can't make changes that take time to filter in, but I think we should definitely bias our risk equations to finding solutions that work to protect the maximum number of users. That's why I'm inclined to favor solutions that look at whether something is capable of X, rather than just intended for X.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We've definitely got options for CAs that wish to carve out issuance, and we can explore more ways to carve out such issuances that don't negatively impact the ecosystem, but I'm loathe to endorse solutions where you're only protected if you're on the sharpest of bleeding edges.</div></div>