[cabf_validation] Revision to OU requirements

Ryan Sleevi sleevi at google.com
Mon Aug 24 10:23:49 MST 2020


> I also think we should remove the exception for OU from 9.6.1 (3), strike
> 9.6.1 (4) completely.  As has been discussed ad nauseum in other contexts,
> what does “misleading” actually mean? It’s not auditable and provides no
> meaningful normative guidance.  IMO we should implement ACTUAL verification
> requirements for the OU field in 3.2.2.1.
>

The conversation in Bratislava was, I think, much more productive and
germane: Why permit the OU at all?

In the several months since, we haven't really seen any identified or
enumerated use cases forthcoming from CAs. The in-person discussion seemed
largely to be around "Customers ask for it" (in which case, the goal was
for CAs to determine why) or "They use it for certificate inventorying",
which there seemed consensus that this was at odds with the general
direction of improving automation and certificate management.

I think a reasonable next step would be to forbid issuance of any
certificate with OU. If there are use cases relevant to the establishment
of SSL/TLS connections, particularly in web browsers, we should work to
identify concretely those use cases, so we can discuss both their semantic
expression (i.e. beyond OU) and their verification expectations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200824/61f43114/attachment.html>


More information about the Validation mailing list