<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 19, 2017, at 2:58 PM, Adam Langley <<a href="mailto:agl@google.com" class="">agl@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 19, 2017 at 1:14 PM, Peter Bowen via Public <span dir="ltr" class=""><<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am one of the many who has raised the topic, and there has been strong consensus from both IETF and ITU-T + ISO/IEC that the inclusion of an id-ce-extKeyUsage extension in a Certificate (whether CA-certificate or end-entity certificate) constrains the usage of the public key in the certificate, not the usage of public keys certificated by the CA named in the certificate. This runs contrary to the usage of the id-ce-extKeyUsage extension in Microsoft, OpenSSL, and Mozilla NSS, and many other certificate validation libraries.</blockquote><div class=""><br class=""></div><div class="">I believe that it was Microsoft who first widely made EKU a "path property" rather than only affecting a specific certificate. I could have my history wrong, but I commend whoever it was. Having EKUs in intermediates constrain EKUs down the path is useful and less surprising—evidenced by widespread implementation practice.</div><div class=""><br class=""></div><div class="">Standards should codify and unify practice. In this case the standard diverges from reality without good reason, thus the standard has a flaw.</div><div class=""><br class=""></div><div class="">(Whether Gmail should be requiring an intermediate EKU is a separate question, but I consider appeals to the standard to be a non-argument here.)</div></div></div></div></div></blockquote><br class=""></div><div>I agree that having the ability to constrain EKUs down the path is very useful and I’ve also heard that it was Microsoft who did this first.</div><div><br class=""></div><div>That being said, I am well aware there are large PKI deployments that depend on the alternative meaning. This keeps being the sticking point when trying to propose updating the standards.</div><div><br class=""></div><div>I’m all in favor of adding a new constraint type explicitly for EKU, adding a new flag to indicate that the EKU constraint is “indirect” (meaning down the path), or coming up with some other solution. But I do think that we need to allow both the direct and indirect interpretations co-exist and not set requirements that assume one implementation or the other.</div><div><br class=""></div><div>I also favor, in this specific case, supporting existing PKIs that issue identity certificates, as it seems like a very reasonable use case to be able to sign an email using my government issued ID.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div></body></html>