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

Wed Jan 27 15:05:51 UTC 2021

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.

________________________________
From: Ryan Sleevi <sleevi at google.com>
Sent: Thursday, January 14, 2021 21:34
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>
Cc: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements

On Thu, Jan 14, 2021 at 3:10 PM Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com<mailto:Paul.vanBrouwershaven at entrust.com>> wrote:
I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement.

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

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.

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.

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.

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.

Another example, we also allow locally accepted abbreviations for the subject organization name, why would this not be accepted for the OU field?
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.
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.

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.

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.

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.

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