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

[Ryan Sleevi]

On Thu, Jan 14, 2021 at 3:10 PM Paul van Brouwershaven <
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/20210114/3653ae96/attachment.html>