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

[Ben Wilson]

I agree.

On Fri, Jun 4, 2021 at 8:28 AM Paul van Brouwershaven <
Paul.vanBrouwershaven at entrust.com> wrote:

> As discussed during the validation subcommittee teleconference, I have
> updated the proposal to state:
>
>    __Required/Optional:__ __Deprecated__.
>    __Prohibited__ if the `subject:organizationName` is absent or the
> certificate is issued after August 31, 2022.
>
> Comparing cabforum:main...vanbroup:oudeprecation · cabforum/servercert
> (github.com)
> <https://github.com/cabforum/servercert/compare/main...vanbroup:oudeprecation>
>
> If we agree and @Ben Wilson <bwilson at mozilla.com> and @Chema Lopez
> <clopez at firmaprofesional.com> are still willing to endorse, I will start
> the ballot process.
> ------------------------------
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Tuesday, June 1, 2021 17:20
> *To:* Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>
> *Cc:* CA/Browser Forum Validation SC List <validation at cabforum.org>;
> Chema Lopez <clopez at firmaprofesional.com>; Ben Wilson <bwilson at mozilla.com
> >
> *Subject:* Re: [EXTERNAL] Re: [cabf_validation] Deprecating and
> prohibiting `subject:organizationalUnitName`
>
>
>
> 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/20210604/f285d18a/attachment-0001.html>