<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 11:55 AM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter - you have addresses a lot of issues at a very abstract level.  I'm curious -- is there a current problem or need you are addressing?  (If so, can you describe so we all have context?)  Or are you approaching this more from an intellectual perspective, simply trying to set limitations which might be useful in the future if we have a question about the scope of various guidelines?<br></blockquote><div><br></div><div>Kirk, this topic has been discussed repeatedly for over a year, so there should be ample context. I'm a bit surprised you don't recognize it as such, given you've participated in these discussions.</div><div><br></div><div>The question is simple: What is the scope of the BRs? The current definition of "intended to be used" leaves great ambiguity: If something is technically capable of being used, is that an expression of intent? Is intent simply a matter of a CA saying "Oh, yeah, don't do that?" Can I issue a cert for <a href="http://google.com">google.com</a> and claim it's not intended to be used for TLS, but S/MIME? Even when it has the tls-serverAuth EKU?<br></div><div><br></div><div>This has been discussed in the context of root programs (see the debates with Jody on audit requirements). This has been discussed in the context of audits (what does WebTrust examine). This has been discussed in the context of program requirements (Mozilla's repeated clarifications). You've heard comments from the US Federal PKI with respect to EKU processing. We've had discussions in the IETF PKIX group before it was shuttered (and that really speaks to how long this conversation has been ongoing) about EKUs. And yet still we persist with the ambiguous language, in part, because the conversation gets stalled.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also -- does this indirectly tie into the work of the new Governance Change Working Group - meaning, does the proper scope of any guidelines tie into the proper scope of the work and membership of the Forum?<br></blockquote><div><br></div><div>Not necessarily.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am wary of adopting new rules in the abstract without having a better understanding (including examples, if possible) of exactly what problem we are addressing.   Otherwise, we could adopt a limitation only to discover that we didn't like it when a particular situation arises (Gerv gave a good example)</blockquote><div><br></div><div>Multiple examples have been provided over several years, considering that this is a conversation that has been ongoing for some time. Peter's questions attempt to rephrase the debate, given that it has in some ways reached a log-jam for some members.</div><div><br></div><div>Given the nature of members' PKI, and given the multiple statements from the auditors as to how they approach audits, root programs are understandably concerned. If a root program says "Everything technically capable must adhere to the BRs", but the BRs say they only cover certificates "intended to be used", how do we reconcile that conflict? The browsers clearly have a specific interpretation in mind (technically capable = intent), but formalizing that into the BRs is seemingly obstructed at every attempt, even with the browsers having that consistent expectation.</div></div></div></div>