<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Slack-Lato;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I did not propose to eliminate OU altogether in this ballot. Digicert seems to already be deprecating OU for their own issued certificates, and Sectigo agrees that removal of OU is probably the best path forward, however given the feedback
I’ve received both on list and privately, I don’t believe there is sufficient consensus for a ballot completely banning the use of the OU field to pass. As such, I maintain that the current wording in Sections 7.1.4.2.2 and 9.6.1 needs to be fixed and OU,
if used, should be fully verified just like any other field in the Certificate Subject. What this ballot is missing and what I’m asking this group to help contribute, is the sensible rules as to HOW the OU should be verified, and if we can’t come up with
how that should be done, I’ll revert to the suggestion to undertake complete removal of OU.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Rich<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Validation <validation-bounces@cabforum.org> <b>
On Behalf Of </b>Richard Smith via Validation<br>
<b>Sent:</b> Tuesday, September 8, 2020 1:59 PM<br>
<b>To:</b> Ryan Sleevi <sleevi@google.com>; CA/Browser Forum Validation SC List <validation@cabforum.org>; Bruce Morton <Bruce.Morton@entrustdatacard.com><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Revision to OU requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt">
<p class="MsoNormal" style="line-height:12.0pt;background:#FAFA03"><span style="font-size:10.0pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the
content is safe.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">OK, here’s hoping I’ve done this right. I’ve created a pull request with my proposed ballot text here:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://github.com/cabforum/documents/pull/211">https://github.com/cabforum/documents/pull/211</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Rich<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org">validation-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ryan Sleevi via Validation<br>
<b>Sent:</b> Wednesday, September 2, 2020 4:38 PM<br>
<b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com">Bruce.Morton@entrustdatacard.com</a>><br>
<b>Cc:</b> CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Revision to OU requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt">
<p class="MsoNormal" style="line-height:12.0pt;background:#FAFA03"><span style="font-size:10.0pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the
content is safe.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Right, but that's slightly different than the point I was making :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Up to (through?) AMT 7.0, you could only use several commercial CAs, and only with SHA-1.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">From AMT 7.0+, an organization can add their own CA to the set of management hashes, so there's no need to obtain a commercial CA certificate to function.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While AMT supports a variety of commercial CAs still, expanded as part of the Great SHA-1 deprecation, these aren't
<i>required</i>, which is the scenario that I think we're trying to understand re: VMware. That is, if the Forum, or browsers, took a step to forbid OU, then there are options for both commercial CAs (using the root rotation I mentioned) and enterprises using
AMT (using a private CA, whether commercially-managed or privately-managed) to function.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">AMT using commercial CAs baked into firmware is a bit like the payment terminal scenario, or, for that matter, certificate pinning, both of which Forum members have largely recognized as problematic for security, interoperability, and of
course, for CAs not on those lists, competition. Luckily, we have options to avoid that.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Sep 2, 2020 at 5:17 PM Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com">Bruce.Morton@entrustdatacard.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Intel trusts a number of public CAs,
<a href="https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Frootcertificatehashes.htm" target="_blank">
https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Frootcertificatehashes.htm</a>.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Bruce.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>
<br>
<b>Sent:</b> Wednesday, September 2, 2020 4:59 PM<br>
<b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>><br>
<b>Cc:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL]Re: [cabf_validation] Revision to OU requirements<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><strong><span style="font-family:"Calibri",sans-serif;color:red">WARNING:</span></strong> This email originated outside of Entrust Datacard.<br>
<strong><span style="font-family:"Calibri",sans-serif;color:red">DO NOT CLICK</span></strong> links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I thought private CAs for AMT were supported since AMT 7.0, which was circa-2010/2011 if I remember correctly?<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Prior to that, Intel hard-coded a list of commercial CAs into the firmware of their chips, which is just... many levels of "don't do that". On the upside, it's possible to smoothly
transition to new roots, for the commercial CAs still wanting to provide those certificates, by spinning up new roots, cross-signing new with old, issuing BR-compliant certs from new, and withdrawing old from root stores (so they could issue non-BR compliant
certs). Basically, SHA-1 transition, but more structured, but I think that should only matter for hardware more than 10 years old, and I think the old stuff only supported SHA-1 anyways?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Sep 2, 2020 at 4:53 PM Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Intel also uses the OU for Intel VPro/AMT use case where they require OU= Intel (R) Client Setup Certificate.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a href="https://www.intel.com/content/dam/support/us/en/documents/software/software-applications/Intel_SCS_Deployment_Guide.pdf" target="_blank">https://www.intel.com/content/dam/support/us/en/documents/software/software-applications/Intel_SCS_Deployment_Guide.pdf</a>
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Bruce.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Jeremy Rowley via Validation<br>
<b>Sent:</b> Wednesday, September 2, 2020 4:29 PM<br>
<b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br>
<b>Cc:</b> CABforum3 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL]Re: [cabf_validation] Revision to OU requirements<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><strong><span style="font-family:"Calibri",sans-serif;color:red">WARNING:</span></strong> This email originated outside of Entrust Datacard.<br>
<strong><span style="font-family:"Calibri",sans-serif;color:red">DO NOT CLICK</span></strong> links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Yeah – we wanted to see what would happen if we turned it off. So far, there hasn’t been a lot of noise. This is the first one we’ve encountered.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">VMware generate the OU as part of the cert request to create a unique identifier. The tool uses that unique identifier to do the installation. Removing the OU is breaking the VMware
install tool and causing it not to load the certificate. We’re reaching out to them to see if we can get them to update their software and stop requiring OU.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>
<br>
<b>Sent:</b> Wednesday, September 2, 2020 2:23 PM<br>
<b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br>
<b>Cc:</b> CABforum3 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>; Richard Smith <<a href="mailto:rich@sectigo.com" target="_blank">rich@sectigo.com</a>><br>
<b>Subject:</b> Re: [cabf_validation] Revision to OU requirements<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Sep 2, 2020 at 4:14 PM Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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: <a href="https://kb.vmware.com/s/article/2044696" target="_blank"><span style="font-size:11.5pt;font-family:"Slack-Lato",serif;background:#F8F8F8">https://kb.vmware.com/s/article/2044696</span></a><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks Jeremy! I saw DigiCert was taking a good step here, in <a href="https://knowledge.digicert.com/alerts/ou-removal.html" target="_blank">https://knowledge.digicert.com/alerts/ou-removal.html</a>
, and think that's a model for all CAs (by virtue of the BRs)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Much like past work on working out interoperable, standards-based approaches to IP addresses ( <a href="https://cabforum.org/guidance-ip-addresses-certificates/" target="_blank">https://cabforum.org/guidance-ip-addresses-certificates/</a>
), it'd be great to understand the problem more to see what options we have.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>