As it's reminded into the lint's code itself....

We also include the OU attribute here, even though it is now banned, because this lint
deals with a more general requirement that came into force long before the OU ban,
and there is already another lint that deals with the OU attribute specifically.

Since the lint has an effective date of util.SC16EffectiveDate (2019-04-16), when the OU was still allowed (it only became prohibited on 2022-09-01), I am not clear why @XolphinMartijn asked to remove it from this lint's table of allowed subject attributes. I am entirely in favour of restoring it.

As I pointed out in the in-code comments, there is already another lint that specifically deals with the OU prohibition (lint_organizational_unit_name_prohibited.go) based on its own and correct effective date (util.CABFBRs_OU_Prohibited_Date).

Since the lint has an effective date of util.SC16EffectiveDate (2019-04-16), when the OU was still allowed (it only became prohibited on 2022-09-01), I am not clear why @XolphinMartijn asked to remove it from this lint's table of allowed subject attributes. I am entirely in favour of restoring it.
@XolphinMartijn and @defacto64 I would appreciate it if you would chime in on whether-or-not you may an argument against the above. If not then I will move forward with the change.

I'm still in favor of not having OU in the allow list here. But I can live with it if you take a different direction ;)

I will expand on why I personally find it the better approach, which boils down to two items:

1. Confusion. Yes, there's a comment in the code that it isn't allowed by the BRs. But, we also know people don't always read the manual!.
2. Design Consistency. Now granted, I don't currently know what the design intent is here, and also, in this case it doesn't have too much effect. But IIUC, there's no such thing as a "EffectiveEndDate" in zlint. Now imagine there's a lint for an existing "MUST" requirement, but CABF changes that to a "MUST NOT". I would in such a case expect that zlint has to either update the existing lint, or remove it and add a new lint for the new requirement. Any such a change would not take into account any certificates issued prior to the change.
   Again, in this case that's not as much of an issue, but it is why I took that thought and applied it to this lint, especially as it was a newly added lint

But IIUC, there's no such thing as a "EffectiveEndDate" in zlint

Actually, the Lint struct includes an IneffectiveDate field (very seldom used).

Apart from that, let's take for example this EV certificate:
https://search.censys.io/certificates/399d72aaffa8e653567aed2cb99311160dccf54ca8b4a589b8099e9b402fcb04

Since it was issued on 2022-06-23, when the OU was still allowed, IMO it's wrong to raise an error about the OU attribute being present in the Subject of this cert. This would not have happened if it was not for PR#903.

My understanding, and it seems completely logical to me, is that Zlint should detect if the certificate has any features that break the rules that were in place at the time when the certificate was issued. If a certificate that was good when it was issued later "becomes" bad (as the rules change over time), it would not be correct to dispute something with the issuing CA.

Yes, there's a comment in the code that it isn't allowed by the BRs. But, we also know people don't always read the manual!.

For my part, I actually spent well over an hour combing over the BRs trying to understand why the heck is in the allow list to begin with. All that work instead of scrolling up in the code file 🤕