<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 2, 2020 at 4:14 PM Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br></div><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_-5723674718053218522WordSection1">
<p class="MsoNormal">We’ve been working to shut off OU completely to see if there are issues with doing so.  So far, we’ve found one automation tool that requires OU:  <span style="font-size:11.5pt;font-family:Slack-Lato;background:rgb(248,248,248);text-decoration:none"><a href="https://kb.vmware.com/s/article/2044696" target="_blank">https://kb.vmware.com/s/article/2044696</a></span></p></div></div></blockquote><div><br></div><div>Thanks Jeremy! I saw DigiCert was taking a good step here, in <a href="https://knowledge.digicert.com/alerts/ou-removal.html">https://knowledge.digicert.com/alerts/ou-removal.html</a> , and think that's a model for all CAs (by virtue of the BRs)</div><div><br></div><div>I'm hoping you can share more details about the issue there. Are you saying the system doesn't load a publicly-trusted certificate if it's missing the OU field, or merely that their tool produces CSRs with the OU field populated, as part of ensuring a globally unique DN?</div><div><br></div><div>Much like past work on working out interoperable, standards-based approaches to IP addresses ( <a href="https://cabforum.org/guidance-ip-addresses-certificates/">https://cabforum.org/guidance-ip-addresses-certificates/</a> ), it'd be great to understand the problem more to see what options we have.</div><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_-5723674718053218522WordSection1"><div><div><div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div>