<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 10:05 AM 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 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></blockquote><div><br></div><div>Paul,</div><div><br></div><div>That's an interesting way to frame the question, and seems to reflect some of the problematic practices CAs used to perform, which thankfully, the CA/Browser Forum has forbidden.</div><div><br></div><div>You may recall, for example, that Domain Authorization Documents are no longer accepted as proof of domain, precisely because they lack the necessary validation assurance. If we accept the framing of your question, then it seems that you'd be arguing that any verified Legal representative should be able to attest to control any domain name, and that's a perfectly fine and secure system. For that matter, applying more generally, the assumption of Legal representation should be sufficient, by the logic of your question, to authorize any delegation of domain validation.</div><div><br></div><div>Thankfully, we know that browsers, and the Forum at large, have resoundingly rejected this. The Forum forbids delegation of domain validation, and explicitly prohibited the use of Domain Authorization Documents, precisely because they don't meet the level of assurance necessary. This was, of course, readily obvious, when considering "What are the consequences or recourse available if a legal opinion, from a party authorized in some jurisdiction, claimed that a malicious party operated <a href="http://google.com">google.com</a>, rather than Google Inc". It was plain to see, to nearly everyone, that the consequences of such a thing would be disastrous, that limited recourse would be available to Google (depending on the jurisdiction in which the entity operated), and the CA would inevitably claim they did everything right, because they followed the letter of the requirement.</div><div><br></div><div>Certification Authorities exist for one task: to issue certificates that contain _validated_ attributes that relying parties can rely upon. We have documents like the Baseline Requirements to ensure consistency among those attributes, for the purposes of TLS authentication within Browser (Certificate Consumers) products. Setting aside the very fundamental flaws in your OU proposal, regarding the fact that these attributes are not used for the purpose of TLS authentication, it's very clear and obvious that a proposal that simply relies upon self-attestation is, fundamentally, not a validation process, and merely transposition.</div><div><br></div><div>Consider that a secondary purpose of the Baseline Requirements is to provide assurance, to Relying Parties, about the processes used to validate the information. As we've seen over the past decade, the industry has lost significant confidence in the competence and operation of a number of Certification Authorities, in part, because despite claiming to follow consistent guidelines, they failed to do so in practice. This has been readily detectable by comparing the outputs of a CA - the certificates - with the inputs - the appropriate and authoritative data sources, whether they be DNS or the appropriate registry for the jurisidction in question. One of the main activities of the Forum, over the past number of years, has been to move requirements from "the CA has an opinion that" to "the CA followed a defined and verifiable process that". A good example of this is SC30, in which CAs are required to disclose the sources they consider acceptable for validating business information, rather than simply requiring that they maintain an (internal only) list of acceptable sources. This is with the explicit goal of moving the industry towards consistent and verifiable processes.</div><div><br></div><div>I highlight this, because a process that depends on verified Legal opinions lacks the transparency, consistency, and independent verifiability necessary, at least as proposed. As we've seen with respect to audits for subordinate CAs, we know of ample situations in which CAs inappropriately rely on the judgement or opinion of an unqualified third party, but due to the subjectivity permitted by the Requirements at the time, argue that this is not a failure of their basic duties of a CA. For example, relying on audits for subordinates that lack the necessary and required information, overlooking aspects of reports due to the CA's unfamiliarity with the necessary audit standards, or from auditors not appropriately qualified. If we learn from this past experience, it seems obvious that a substantial risk here is a CA inappropriately relying upon such a verified Legal opinion, either from an entity not appropriately qualified (but the CA mistakenly subjectively believes they are), or as a way of attempting to dismiss responsibility for validation, by instead blaming the third-party for any issues. This is not an acceptable outcome.</div><div><br></div><div>All of this is important context to highlight the unacceptable risks with outsourcing what is nominally the core competency and expectation of a CA, the danger to relying parties and browsers in permitting CAs to do this, and the challenges and legal complexities that exist for such a method. Of course, most of this is mooted by the simple fact that such fields are not necessary for the establishment of TLS connections by browsers, and thus, for whatever value they have in certificates used for other purposes, are not needed in the certificates used by browsers. The risks of accepting such certificates, however, and the fundamental and structural challenges to mitigating those risks appropriately, is, however, simply untenable.</div></div></div>