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

Fri Jun 4 14:28:20 UTC 2021

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<mailto:bwilson at mozilla.com> and @Chema Lopez<mailto: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<mailto: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/eb6c0ff4/attachment.html>