<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Ryan, is it correct to state that your opinion we can't trust a verified Legal representative of an organization to provide the name of an organizational unit within the constraints we have defined in this proposal?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt">I'm asking this because at the end of the day, the Legal representative is the source of trust for many legal-entity attributes used for legal entity identity validation
on which CAs and other society pillars (government agencies, banks, property authorities, justice system and so on) rely on.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Ryan Sleevi <sleevi@google.com><br>
<b>Sent:</b> Thursday, January 14, 2021 21:34<br>
<b>To:</b> Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com><br>
<b>Cc:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; CA/Browser Forum Validation SC List <validation@cabforum.org><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Thu, Jan 14, 2021 at 3:10 PM Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com">Paul.vanBrouwershaven@entrust.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div>
<blockquote style="color:rgb(102,102,102); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; border-left:3px solid rgb(200,200,200); border-top-color:rgb(200,200,200); border-right-color:rgb(200,200,200); border-bottom-color:rgb(200,200,200); padding-left:1ex; margin-left:0.8ex">
<div><span style="font-size:14px; background-color:rgb(255,255,255); display:inline">I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement.</span></div>
<div style="margin:0px; font-size:14px; background-color:rgb(255,255,255)"><br>
</div>
<div style="margin:0px; font-size:14px; background-color:rgb(255,255,255)">For example, it still relies on ambiguous, subjective interpretations, which has shown to result in a number of incidents for CAs. "Local business register" and "locally accepted abbreviation"
are exactly the sort of issues that the Validation WG sought to meaningfully address, and which Entrust here has failed to do. Equally, the presumption of trust in the Applicant data is the very antithesis of validation, yet remains a core component of this
proposal.</div>
</blockquote>
<div style="margin:0px"><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">In the initial version we proposed the same language as currently used in section 3.2 of the BR, this version is trying to address your comments
to that version. I'm happy to create a definition for "Local business register" or you can suggest another term for official business registers. I don't think it's fair to argue that this proposal 'suffers the same basic issues' based on language that is currently
accepted in other sections and not easily to replace without forbidding identity information in general.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Paul, I'm sure you're aware of the considerable effort here to ensure consistency on these points, such as Ballot SC30, so surely you're aware that there are explorations.</div>
<div><br>
</div>
<div>However, as has already been addressed previously, with respect to _this_ specific field, those assumptions even valid for SC30 don't hold. Just because we've got a broken process (with demonstrable CA incidents) doesn't mean it's a solid foundation here.</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div>
<div style="margin:0px"><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">While I agree we should try to address all issues in the current requirements, but let's start that process instead of removing/blocking improvements
based on the same principles.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I believe we'll likely have to simply agree to disagree: this is not a meaningful improvement, compared to the issues identified. Arguing that we should "do something" rather than doing nothing is compelling, and that's exactly why it's relevant to remove
this field, and ensure that any further introduction is sound from first principles.</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div>
<div style="margin:0px"><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Another example, we also allow locally accepted abbreviations for the subject organization name, why would this not be accepted for the OU
field?</span></div>
<blockquote style="color:rgb(102,102,102); font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; border-left:3px solid rgb(200,200,200); border-top-color:rgb(200,200,200); border-right-color:rgb(200,200,200); border-bottom-color:rgb(200,200,200); padding-left:1ex; margin-left:0.8ex">
<div style="margin:0px; font-size:14px; background-color:rgb(255,255,255)"><span style="font-size:14px">As stated, we do not see a viable path forward for this, not (as it has been unfortunately stated) as an attempt to shut down discussion, but precisely because
this fails to meet the bare minimum of addressing the systemic issues, and is thus not a remotely viable or acceptable "solution" to the problems identified and, unfortunately, practiced by CAs.</span></div>
</blockquote>
</div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Personally, I think that the strong opinionated position from Google and the negativity towards any attempt to strengthen the requirements has prevented participation
in a progressive discussion on improving the requirements on this list.</span></div>
</div>
</blockquote>
<div><br>
</div>
<div>We've been incredibly supportive and receptive towards proposals that meaningfully improve things. This does not. The attempt to position all feedback as negative is misguided at best, disingenous at worst, and reflects a clear misunderstanding about the
issues to be solved and the principles behind these issues.</div>
<div><br>
</div>
<div>I realize that there are more substantial disagreements here, with respect to identity information as it applies to TLS certificates used in browsers. In particular, it would seem as if your disagreement about the operational risks to servers, and the
security risks to users, that such information would pose, somehow justifies ignoring or dismissing our concerns. However, it also demonstrates exactly why we're at the impasse: there's no meaningful progress on understanding and addressing the concerns we
have and have raised. It's not negativity to suggest that "2+2 = 5" is wrong, nor is it negativity to point out that this continues to fail to address concerns, despite the good faith efforts in explaining them.<br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">I suggest that the validation working group starts to address the existing language in the requirements (and as proposed for this ballot) prior to any decision
about the OU field removal.</span> </div>
</div>
</blockquote>
<div><br>
</div>
<div>We've spent 2+ years discussing this. Entrust came in at quite literally the last second with the suggestion that somehow we'd failed to consider things, and yet, as has been shown throughout, these options have been thought through, and still fail to
address the concerns. That's not a failure on the WG part to engage, but a reflection of the innate problem of introducing subscriber-attested, unverified, non-authoritative data. Similarly, throughout this ballot, it has equally failed to even acknowledger
the second-order effects on the security of users such data has, whether it be through the display of such information to end users, or the operational deployment practices, as recently seen on the questions@ list, which introduce significant risk to agility
and security. Treating this as "only" a validation problem is to disregard the years of discussion had, and however tempting that might be, it's not progress.</div>
</div>
</div>
</div>
</body>
</html>