<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7557800323062100601WordSection1">
<p class="MsoNormal">I also think we should remove the exception for OU from 9.6.1 (3), strike 9.6.1 (4) completely.  As has been discussed ad nauseum in other contexts, what does “misleading” actually mean? It’s not auditable and provides no meaningful normative
 guidance.  IMO we should implement ACTUAL verification requirements for the OU field in 3.2.2.1.</p></div></div></blockquote><div><br></div><div>The conversation in Bratislava was, I think, much more productive and germane: Why permit the OU at all?</div><div><br></div><div>In the several months since, we haven't really seen any identified or enumerated use cases forthcoming from CAs. The in-person discussion seemed largely to be around "Customers ask for it" (in which case, the goal was for CAs to determine why) or "They use it for certificate inventorying", which there seemed consensus that this was at odds with the general direction of improving automation and certificate management.</div><div><br></div><div>I think a reasonable next step would be to forbid issuance of any certificate with OU. If there are use cases relevant to the establishment of SSL/TLS connections, particularly in web browsers, we should work to identify concretely those use cases, so we can discuss both their semantic expression (i.e. beyond OU) and their verification expectations. </div></div></div>