[cabf_validation] [EXTERNAL] Re: Deprecating and prohibiting `subject:organizationalUnitName`

[Ryan Sleevi]

On Fri, May 28, 2021 at 2:19 PM Paul van Brouwershaven <
Paul.vanBrouwershaven at entrust.com> wrote:

> Hi Ryan,
>
>
>
> The reason that this proposal is requiring a documented case-by-case
> exception is to collect concrete evidence like you are requesting and limit
> the use case to organizations that depend on the OU and need more time to
> migrate to an alternative solution.
>
>
>
> There are several use-cases presented, including tracking, pining,
> organizational unit identification for management, and most importantly
> mTLS. This last use case is where we see the biggest impact and need for
> time, as these organizations need to change their applications, ldap or
> move off the public PKI to a private PKI to continue their operations.
>

I'm glad we're in agreement regarding Deprecation, but I think we're in
clear disagreement about the reasonableness of your timeframe, as
previously mentioned.

For example, your proposal suggests that, until May 31, 2022, the OU field
is acceptable. That, however, is in clear disagreement with the past
five-odd years of discussion in the Forum, and is so firmly disconnected
from the reality and security needs of users that we simply cannot support
or endorse that perspective. That is, the OU field has been SHOULD NOT for
quite some time. Whether you view this, as some CAs have, as happening
during the initial discussions and concerns of OU, or if you view it in the
more recent discussions for the past year, there is no reasonable position
that can be had to suggest that the OU field, today, is one that is without
issue. Suggesting, then, that we continue for another year before
communicating that to users is not only problematic, but it suggests that
there is limited value to be had in engaging in the CA/Browser Forum, if
CAs will ignore such discussions.

Luckily, while I realize Entrust Datacard may not yet be at the level of
the rest of the industry, it's encouraging to see that a number of CAs have
engaged in efforts over the past year to communicate this SHOULD NOT to
their customers. We know that, as a deprecation, it still allows such
certificates to be obtained, and so there is no meaningful or legitimate
reason that SHOULD NOT cannot be or should not be effective immediately.

So the core of our discussion is MUST NOT. The SHOULD NOT period (i.e. for
the past year) serves two purposes:

   - What are the use cases?
   - What is the transition time necessary for those use cases, relative to
   the risks?

Your latest reply seems to support the discussions of the past year:
namely, we have a relatively clear accounting of the general use cases,
even if some CAs may not be familiar with which of their customers are
affected. Luckily, repeated calls by Google and others for CAs to identify
their customers have meant that, at this point, it's somewhat inexecusible
for those CAs that still are not familiar with their customers' needs,
because ample opportunity has existed to find out. Indeed, we've seen quite
a few CAs successfully do so, as proof of this.

So what remains, then, is a question about what transition time is
necessary. This is an area where it's understandable to expect CAs and
Browsers to disagree. CAs are focused on their revenue-generating customers
and reflecting their needs, and understandably, the "ideal" timeframe for
these customers is "Without any changes at all". This is why my previous
message provided a detailed breakdown of timeframes, to highlight why
Entrusts' proposal is problematic as proposed. However, equally problematic
is an assumption that "Without any changes at all" is a reasonable default
position when it comes to SSL/TLS certificates. This is not a new
discussion - it's a recurrent theme when it comes to certificate lifetimes,
CAs investing in automation (both internally and when interfacing with
customers), revocation timelines and expectations, and the sunsetting of
certain CAs, to give a few examples. We know user security is meaningfully
harmed when CAs and site operators fail to invest in improving this cycle,
and that's why, for the past decade, Google's focus has been on working
with CAs that are committed to improving this cycle, helping organizations
automate and make such deployment seamless.

Since much of my previous e-mail seems to have been ignored, at least with
respect to carrying it through to its logical conclusions, here's a clearer
position for discussion:

i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11)

   __Required/Optional:__ __Deprecated__.

   __Prohibited__ if the `subject:organizationName` is absent or the
certificate is issued after May 31, 2022.


You can see that this date here reflects a significant relaxation of our
previous proposals, reflecting the positive feedback from CAs and their
customers that engaged in good-faith discussions about the challenges, but
I fear that anything later is something that is simply not reasonable to
the discussions had to date and the concerns raised.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210601/53c3b3c8/attachment.html>