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

Fri May 28 18:07:32 UTC 2021

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.

The deprecation timeframe should give (most) subscribers the time to stop using the OU and move to alternative solutions, the organizations that require more time to plan, budget and setup a private PKI (for example) would require more time and these fall in the documented exception period.

I think it’s reasonable to state that Prohibited values equals MUST NOT and a Deprecated value is a weaker form of SHOULD NOT.

The following change to the proposed language reflects this interpretation better:

i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11)
   __Prohibited__ if the `subject:organizationName` is absent.
   __Prohibited__ after May 31, 2024
   __Deprecated__ discouraged, SHOULD NOT be included after May 31, 2022 permitted until prohibited when documented as case-by-case exception.

Thanks,

Paul

From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, May 25, 2021 5:01 PM
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Cc: Chema Lopez <clopez at firmaprofesional.com>
Subject: [EXTERNAL] Re: [cabf_validation] Deprecating and prohibiting `subject:organizationName`

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hi Paul,

I'm glad to see Entrust has recognized that its previously suggested approach to OU lacks consensus.

However, we have yet to see any data to support the 2024 deadline, especially when this timeline is functionally not effective deadline of May 31, 2025, due to certificate lifetimes. Given the data presented around the use, and misuse, of OU, and the many CA incidents, it does not seem like a 2024 date can be reasonably justified, but perhaps there is more concrete data you would like to share? Certainly, Certificate Transparency offers us a clear empirical roadmap to both those affected and the (previously discussed) use cases, much better than any survey or "customer wishlist" would.

As per past discussions in the Forum regarding acceptable timeframes, I think the reasonable timeframe that we could endorse would look to see it immediately moved to a SHOULD NOT, with a goal of MUST NOT on roughly the timeframe you propose (May 2022, or approximately one year out). This would allow us to ensure that data is promptly gathered as soon as possible, through the SHOULD NOT transition, and ensure that if there is data that warrants it, relevant to the risk to users and certificate holders, that we can revisit that timeline if it proves to be necessary.

However, the process of "documented case-by-case exception" is, while conceptually interesting, deeply problematic, and something that I don't think we could support. This process fundamentally repeats the mistakes that we're trying to correct with OU, which is to allow a subjective, inconsistent, non-industry standard approach that exposes users and browsers to unnecessary risk, both in interpretation and action. You may recall similar proposals with SHA-1, and the particular repeat failures of CAs to adhere to those processes discussed. We have zero reason to believe things have improved; indeed, evidence to the contrary is readily apparent even in CA non-compliance issues in the past few months. Because of this, while interesting, it certainly does not seem to find the right user security balance.

While these are ultimately things that can be directly addressed by root program policies to the CAs within those root programs, we are certainly interested in seeing if there is a reasonable point in the Forum for discussion. While this draft ballot does not yet factor in the many conversations that have been had, or the concerns that have been raised, we look forward to working with you on a more reasonable timeframe, and with a more reasonable process in play. Again, using the past experiences of the Forum, anything that does not "immediately" SHOULD NOT would be certainly not setting up site operators for success, as they replace certificates this year, but we do believe you're on the right track to gathering and producing explicit documentation on the use cases here as the year progresses, to allow us to revisit if there are any use cases that have not yet been exhaustively discussed.

On Tue, May 25, 2021 at 9:47 AM Paul van Brouwershaven via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
Entrust is proposing this change to deprecate and finally prohibit the `subject:organizationName` as a follow-up to our previous proposal that failed to gain consensus on the way to improve the validation. Ben Wilson from Mozilla and Chema Lopez from Firmaprofesional have indicated to endorse this proposal to deprecation and finally prohibit the OU.

Before we submit the ballot, we would like to know if the members of the validation working group are fine with the definition 'documented case-by-case exception' that is required in this proposal and expects the CA to create or collect documentation on why this exception was required.

i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11)
   __Required/Optional:__ __Optional__.
   __Required/Optional:__
   __Prohibited__ if the `subject:organizationName` is absent.
   __Prohibited__ after May 31, 2022 but allowed as a documented case-by-case exception until and including May 31, 2024.
   __Deprecated__ discouraged until prohibited.

Comparing cabforum:main...vanbroup:oudeprecation · cabforum/servercert (github.com)<https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/main...vanbroup:oudeprecation__;!!FJ-Y8qCqXTj2!LkCSdi3Y8xLWbRQcWc939DT_y-Jq1n9iMefs53Y4Nm799IzlFugWWxPKiBal13CdBkUhYtNm8w$>

Thanks,

Paul

_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto:Validation at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/validation<https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/validation__;!!FJ-Y8qCqXTj2!LkCSdi3Y8xLWbRQcWc939DT_y-Jq1n9iMefs53Y4Nm799IzlFugWWxPKiBal13CdBkXq54Sveg$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210528/0dea3562/attachment-0001.html>