<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;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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">Inline below<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> Ryan Sleevi <sleevi@google.com> <br>
<b>Sent:</b> Tuesday, September 8, 2020 9:57 PM<br>
<br>
<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Thanks Rich.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I can appreciate the effort to "bring clarity to the guidelines", I think this is a much more significant task than your ballot puts forward. As a practical matter, I'll state up front that there is a significant, potentially insurmountable,
barrier towards any approach that does not remove OU entirely.<o:p></o:p></p>
<p class="MsoNormal"><b><i>[Rich Smith] I agree, but I don’t think such consensus currently exists w/in the Forum. This is a draft ballot, and I’ve proposed this as an opportunity for those who disagree to come up with viable, auditable requirements for verification
of the OU field if they want to save it.</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In terms of your specific ballot, not only do you attempt to clarify the language, but you also attempt to remove any obligation of the CA to validate the information.<o:p></o:p></p>
<p class="MsoNormal">In effect, this becomes a freeform field, and that remains deeply troubling, especially given the struggles CAs are facing with strict fields, such as businessCategory, which have an explicit allowlist of specific values. Beyond just making
the validation rules "whatever you say you do in your CP/CPS", it goes a step further, and removes both the obligation to disclose what those rules are,
<b>and</b> any warranties that the CA actually followed those rules. If this was 2007, and we were discussing Baseline Requirements, this might seem like a reasonable solution, as I'm sure it did when it was introduced, but in 2020, we know enough to know this
doesn't work.<o:p></o:p></p>
<p class="MsoNormal"><b><i>[Rich Smith] </i></b><b><i>I would counter that it is and has been pretty much a freeform field since “not misleading” is not any kind of auditable real requirement. What I’ve removed is the exception allowing unverified data to
be inserted in the OU, and I left the job of specifying verification requirements to those who wish to keep using OU.<o:p></o:p></i></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In terms of general principles, however, it becomes even more problematic. I realize this is a longer response than the ballot itself, but considering the Forum keeps having this discussion every time we talk about new attributes, let alone
existing ones such as the OU, it seems useful to lay out some of the principles and expectations, in order to make communication easier and Chrome's goals here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To discuss how the information should be validated requires discussing what the information should be in the first place. In the months since the F2F discussion, no one has brought any use case forward. We know from extant practices that
CAs are keen to add their brandnames, marketing information, or otherwise problematic data, such as "Domain Control Validated", which serves no value to the software using these certificates. To figure out how to validate first requires identifying the use
cases, and those use cases that have been shared are not only hardly compelling, but border on problematic to harmful to security.<o:p></o:p></p>
<p class="MsoNormal"><b><i>[Rich Smith] The one use case I have that I don’t find completely problematic is the insertion of an ICD into the OU field. I didn’t propose it for this because I think that while it is a useful and appropriate addition to the Subject
identity information, I think subject:organizationIdentifier is a better place for it. I’ll discuss that further in another thread.</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">At the end of the day, we need to recognize that for all intents and purposes, X.509 certificates are "just" a signed container format. The lofty ambitions of X.500 and X.520, with the set of key-value attributes for a global naming ontology,
have little to no relevance to X.509, as embodied by RFC 5280. Nothing could be more obvious that the very first effort of the IETF's PKIX working group, working with ITU, resulted in X.509v3, which introduced extensions and wholesale rejected the continued-extension
of the Directory Name, reflecting what was as true and obvious in 1995 as it was in 2020: that the X.500 DIT would never materialize, and X.509, as used in TLS, was simply as an efficient container format.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we view certificates as "just" a container format, then it's clear that we don't need to put every conceivable attribute within the same certificate. There can be multiple certificates, and multiple hierarchies, all providing signed
assertions to different communities, without requiring a single signed assertion (a certificate) from a single CA. Attributes like the organizationalUnitName, which have zero bearing on TLS as used by browsers, fundamentally do not belong in certificates used
by TLS by browsers. CAs are free to issue those certificates, but from hierarchies other than those managed on behalf of and used by browsers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If there is a community of users who use the OU attribute in machine-to-machine communication, for example, they can establish a PKI hierarchy/framework for managing those assertions securely. They could use commercial CAs, they could use
private CAs, that doesn't matter. However, there is no sound reason to make such assertions *<b>also</b>* assertions for TLS. Modern computing is made up of hundreds of certificates on a daily basis, from the peripherals like your mice and keyboard to the
ROM on your motherboard, and thankfully, no one has made the misguided suggestion those need to also be TLS certificates, and this is no different. CAs are free to issue such certificates, using whatever rules they like (as this ballot proposes), but from
trust hierarchies not used by browsers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If the view is that such attributes are useful for user display, then that's all the more reason they don't belong in TLS certificates, which are used by browsers to validate bindings between keys and domains/IP addresses. Those proposing
certificates for user-facing information are free to introduce their own, not-TLS certificates, and explore how to expose that information to users. As X.509 certificates are
<b>just</b> a container format, conceptually no different than CMS, JWT, or heck, even PDF, there's no reason to try to shoehorn everything into one certificate. For use cases of human visibility, there's an even stronger argument for not having them in TLS
certificates: users don't understanding binding of attributes to <b>keys</b>, they're just interested in binding of attributes to
<b>domains</b>, as that's what they're visibly interacting with. It makes sense that a key would be bound to a domain name, but it makes no sense, for the presumed use case, that a key, instead of a domain name, would be bound to an organization or OU.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Attributes like OU, especially as proposed by this ballot, do cause harm. At this point, every CA is well-familiar with the challenges posed by information that is not technically necessary for certificates to function, and which cannot
be machine validated. It hinders issuance, it raises costs and complexity to validate and integrate, it more frequently causes disruptions (such as those caused by revocation, which itself was caused by incomplete processes to begin with), and all to no benefit
for anybody. Precisely because this data cannot be interoperably validated, and especially because this ballot proposes to remove obligations, I cannot see a path forward here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">These objections aren't new; the same concerns were raised with GLEIF, both in the extension of the Subject attribute, which is silly, but also in the general principle of trying to tie everything into a single certificate. For browsers
in particular, and thus the raison d'être for this group, there are plenty of ways to deliver additional certificates, especially for user-visible attributes, as HTTP resources, and without hindering the TLS authentication flow. Although I'm not claiming to
speak for all browsers in this message, you can see many of these same concepts and principles explored in some of the joint-browser responses to the European Commission that have been shared here in the Forum ([1], [2]), that examines the user-harm through
first- and second-order effects, and the technical unsoundness.<o:p></o:p></p>
<p class="MsoNormal"><b><i>[Rich Smith] I’m not going to wade into all this except to say that I don’t believe this is the consensus view of the Forum.</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Rather than wait and spend months discussing all of this, only to reach the same conclusions here, or find we're just recycling the same views circled in the CABF circa-2010, we should just remove the OU now. That provides greater clarity,
and greater user benefit, while ultimately upholds the status quo as reflected in the BRs themselves.<o:p></o:p></p>
<p class="MsoNormal"><b><i>[Rich Smith] And here we are again in agreement, however, this ballot was I guess drafted for those who disagree with us. It represents an olive branch to those who wish to save the OU field, and a challenge: Convince us that you
can define a workable, auditable, normative standard to verify the OU field contents. If no one can propose such standards that we can add to this ballot and get it passed then I will draft another ballot to remove OU with a six month sunset and which I assume
you would happily endorse.</i></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-January/001555.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-January/001555.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-August/002172.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-August/002172.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On Tue, Sep 8, 2020 at 3:10 PM Richard Smith via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</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-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" 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">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Rich<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 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>Richard Smith via Validation<br>
<b>Sent:</b> Tuesday, September 8, 2020 1:59 PM<br>
<b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>; Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: 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>
<div style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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.</span><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>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a href="https://github.com/cabforum/documents/pull/211" target="_blank">https://github.com/cabforum/documents/pull/211</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>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Rich<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 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>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" target="_blank">Bruce.Morton@entrustdatacard.com</a>><br>
<b>Cc:</b> CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;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.</span><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>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Right, but that's slightly different than the point I was making :)<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">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" 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">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" 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">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" 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 5:17 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 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>
</div>
<p class="MsoNormal">_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>