<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 19, 2017 at 6:26 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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.<br></div></div></blockquote><div><br></div><div>As Adam pointed out, how so? These are complimentary, especially if we presume these "EKUs apply only to the cert" implementations strictly adhere to RFC 5280's promotion of Postel's Law, which is that they should not enforce the profile given within 5280/reject deviance from it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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></blockquote><div><br></div><div>Of course, to introduce such a security-critical restriction, we must naturally presume it should be marked critical, correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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></blockquote><div><br></div><div>Is this a remark about product direction/strategy? I'm not sure how to take it.</div><div><br></div><div>Regarding the use of a single certificate/key pair across multiple application spaces, we naturally should be concerned with any possibility of cross-protocol attacks and confusion.</div><div><br></div><div>- The risk of using the same key in the context of both encryption and signing</div><div>- The risk of using the same key across distinct signature algorithms</div><div>- The risk of messages signed with the same key being interpreted in different contexts depending on the protocol (cross-protocol attacks)</div><div><br></div><div>These are all compelling reasons why such a reasonable request is not entirely reasonable.</div></div></div></div>