<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 19, 2017 at 1:14 PM, Peter Bowen 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: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><br></div><div>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><br></div><div>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><br></div><div>(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><br></div><div><br></div><div>Cheers</div><div><br></div><div>AGL</div></div></div></div>