[cabf_validation] [EXTERNAL]Re: Revision to OU requirements

[Ryan Sleevi]

Inline

On Thu, Sep 10, 2020 at 5:04 PM Richard Smith <rich at sectigo.com> wrote:

> In terms of your specific ballot, not only do you attempt to clarify the
> language, but you also attempt to remove any obligation of the CA to
> validate the information.
>
> In effect, this becomes a freeform field, and that remains deeply
> troubling, especially given the struggles CAs are facing with strict
> fields, such as businessCategory, which have an explicit allowlist of
> specific values. Beyond just making the validation rules "whatever you say
> you do in your CP/CPS", it goes a step further, and removes both the
> obligation to disclose what those rules are, *and* any warranties that
> the CA actually followed those rules. If this was 2007, and we were
> discussing Baseline Requirements, this might seem like a reasonable
> solution, as I'm sure it did when it was introduced, but in 2020, we know
> enough to know this doesn't work.
>
> *[Rich Smith] **I would counter that it is and has been pretty much a
> freeform field since “not misleading” is not any kind of auditable real
> requirement.  What I’ve removed is the exception allowing unverified data
> to be inserted in the OU, and I left the job of specifying verification
> requirements to those who wish to keep using OU.*
>

Well, you removed (at least in
https://github.com/cabforum/documents/pull/211 ) the requirement of
specifying the verification requirements. If you meant for that to be done
in this ballot, then I think we're actually in agreement here, which is any
desire to keep it requires specifying the validation requirement, which
requires specifying the use cases.

My concern is you explicitly removed the documentation requirement for CAs,
to document *publicly* in their CP/CPS (per 9.6.1 (4) in the current BRs),
their procedure for ensuring the OU won't contain a name, DBA, tradename,
trademark, address, location, or other text that refers to a specific
natural person or Legal Entity. That is, each CA using the OU needs to
document how they globally (for all possible jurisdictions and natural or
legal persons) validate that the OU won't contain this information. We
know, as a practical matter, that of course that's not realistic, and we
also know that some CAs are currently in violation of the BRs precisely
because they've failed to document this procedure within their CP/CPS, as
required by 9.6.1.

If the argument is "reduce the likelihood" can be satisfied by something
less than what's required by 7.1.4.2.1, and that "rolling a fair die" or
"consulting the auguries" is sufficient to "reduce the likelihood", then I
think we can reasonably say the CA isn't behaving in a trustworthy or
transparent manner.


> These objections aren't new; the same concerns were raised with GLEIF,
> both in the extension of the Subject attribute, which is silly, but also in
> the general principle of trying to tie everything into a single
> certificate. For browsers in particular, and thus the raison d'être for
> this group, there are plenty of ways to deliver additional certificates,
> especially for user-visible attributes, as HTTP resources, and without
> hindering the TLS authentication flow. Although I'm not claiming to speak
> for all browsers in this message, you can see many of these same concepts
> and principles explored in some of the joint-browser responses to the
> European Commission that have been shared here in the Forum ([1], [2]),
> that examines the user-harm through first- and second-order effects, and
> the technical unsoundness.
>
> *[Rich Smith] I’m not going to wade into all this except to say that I
> don’t believe this is the consensus view of the Forum.*
>

I don't doubt it. The very way we found ourselves in this problem is that
CAs have tried, since their introduction, to use single hierarchies. Rather
than acting as notaries public that can certify a variety of documents,
they've positioned themselves as if they can only issue a single type of
certificate that must contain all the information. Yet we've seen this fail
since its introduction, and in virtually every other industry that uses
certificates, this problem doesn't exist. It is specific to TLS, and that's
unfortunate, and this is an area that is continuing to harm compliance with
security-critical expectations and the security of our users. This is going
to change, one way or the other, but I'd love to see us collaborate on how
to enact that change rather than debate that change.


> Rather than wait and spend months discussing all of this, only to reach
> the same conclusions here, or find we're just recycling the same views
> circled in the CABF circa-2010, we should just remove the OU now. That
> provides greater clarity, and greater user benefit, while ultimately
> upholds the status quo as reflected in the BRs themselves.
>
> *[Rich Smith] And here we are again in agreement, however, this ballot was
> I guess drafted for those who disagree with us.  It represents an olive
> branch to those who wish to save the OU field, and a challenge: Convince us
> that you can define a workable, auditable, normative standard to verify the
> OU field contents.  If no one can propose such standards that we can add to
> this ballot and get it passed then I will draft another ballot to remove OU
> with a six month sunset and which I assume you would happily endorse.*
>

Indeed. And it should be fairly "easy" to do this: according to the BRs,
today, the CAs wishing to save the OU field should be documenting their
procedures in their CP/CPS. So they can propose such language from their
CP/CPS.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200910/0ee01038/attachment.html>