[cabf_validation] Deprecating and prohibiting `subject:organizationName`

[Ryan Sleevi]

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> 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://github.com/cabforum/servercert/compare/main...vanbroup:oudeprecation>
>
> Thanks,
>
> Paul
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210525/bf7f5671/attachment.html>