<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="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="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="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="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="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>