<div dir="ltr"><div dir="ltr">Inline </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 5:04 PM Richard Smith <<a href="mailto:rich@sectigo.com">rich@sectigo.com</a>> wrote:</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_1147247595834025739WordSection1"><div><div><div>
</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.<u></u><u></u></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.<u></u><u></u></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.</i></b></p></div></div></div></div></div></blockquote><div><br></div><div>Well, you removed (at least in <a href="https://github.com/cabforum/documents/pull/211">https://github.com/cabforum/documents/pull/211</a> ) the requirement of specifying the verification requirements. If you meant for that to be done in this ballot, then I think we're actually in agreement here, which is any desire to keep it requires specifying the validation requirement, which requires specifying the use cases.</div><div><br></div><div>My concern is you explicitly removed the documentation requirement for CAs, to document <b>publicly</b> in their CP/CPS (per 9.6.1 (4) in the current BRs), their procedure for ensuring the OU won't contain a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity. That is, each CA using the OU needs to document how they globally (for all possible jurisdictions and natural or legal persons) validate that the OU won't contain this information. We know, as a practical matter, that of course that's not realistic, and we also know that some CAs are currently in violation of the BRs precisely because they've failed to document this procedure within their CP/CPS, as required by 9.6.1.</div><div><br></div><div>If the argument is "reduce the likelihood" can be satisfied by something less than what's required by 7.1.4.2.1, and that "rolling a fair die" or "consulting the auguries" is sufficient to "reduce the likelihood", then I think we can reasonably say the CA isn't behaving in a trustworthy or transparent manner.</div><div> </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_1147247595834025739WordSection1"><div><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.<u></u><u></u></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></p></div></div></div></div></div></blockquote><div><br></div><div>I don't doubt it. The very way we found ourselves in this problem is that CAs have tried, since their introduction, to use single hierarchies. Rather than acting as notaries public that can certify a variety of documents, they've positioned themselves as if they can only issue a single type of certificate that must contain all the information. Yet we've seen this fail since its introduction, and in virtually every other industry that uses certificates, this problem doesn't exist. It is specific to TLS, and that's unfortunate, and this is an area that is continuing to harm compliance with security-critical expectations and the security of our users. This is going to change, one way or the other, but I'd love to see us collaborate on how to enact that change rather than debate that change.</div><div> </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_1147247595834025739WordSection1"><div><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.<u></u><u></u></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></p></div></div></div></div></div></blockquote><div><br></div><div>Indeed. And it should be fairly "easy" to do this: according to the BRs, today, the CAs wishing to save the OU field should be documenting their procedures in their CP/CPS. So they can propose such language from their CP/CPS.</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_1147247595834025739WordSection1"><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
</blockquote>
</div>
</div>
</div>
</div>
</div>

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