[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements

[Ryan Sleevi]

On Wed, Jan 27, 2021 at 10:05 AM Paul van Brouwershaven <
Paul.vanBrouwershaven at entrust.com> wrote:

> 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?
>
> 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.
>

Paul,

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.

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.

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
google.com, 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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210127/1a0b0e7e/attachment-0001.html>