CA/B Forum deprecating organizationalUnitName (OU) field effective September 1 2022

[Derek Simmel]

Dear TAGPMA members,

Jeny brought to my attention a notice from Sectigo (formerly COMODO, and the commercial CA service behind the InCommon CAs):
https://sectigo.com/resource-library/due-to-new-rule-ou-field-to-be-deprecated-in-sectigo-issued-certificates-starting-july-1st-2022

"In compliance with upcoming policy changes set out by the CA/Browser Forum, Sectigo will deprecate the population of the Organizational Unit (OU) Field in Certificates starting July 1, 2022. This change will be made ahead of the CA/Browser Forum’s September 1, 2022 deadline. Sectigo will offer a mechanism to temporarily turn off the OU field in Sectigo Certificate Manager to enable customers to test for impact."

The changes are due to a decision by the CA/Browser Forum (the standards body for commercial CAs and Browser vendors) to deprecate and prohibit use of the OU field effective September 1, as described at
https://cabforum.org/2021/06/30/ballot-sc47v2-sunset-subjectorganizationalunitname/

The changes to the policy make the optional organizationalUnitName (OU) field deprecated (i.e. SHOULD NOT be used), and that the OU field is prohibited (i.e. MUST NOT be used) if [[organizationName (O) is not defined] or [date >= September 1, 2022]].

I interpret this to mean that organizationalUnitName (OU) fields in certificates will be allowed until September 1 as long as the certificate also has an organizationName (O) field in it, but that certificates with OU fields must be rejected after September 1, 2022.

(1) In what ways does this change affect your CAs?
(2) Does this change affect operations and authorization services of your relying parties?
(3) Will all currently-valid certificates with an OU field in them need to be replaced before September 1?
(4) What coordination is needed to ease this transition?

- Derek

---
Derek Simmel, TAGPMA Chair
dsi...@psc.edu
+1 (412) 268-1035

[David Groep]

Dear Derek, all,

Just to clarify the ballot results a bit, as for

> (3) Will all currently-valid certificates with an OU field in them need
> to be replaced before September 1?

the answer is "No".
The change is BR (and EV) guidance is "Prohibited if [...] the certificate is
issued on or after September 1, 2022.". So it's about issuance. The certs that
are still valid (depending on the provider, that can be between 90 and 398 days
for CABF BR and EV certs) need not be re-issued. Of course, if you suffer a
revocation after the sunset date, any replacement cert can no longer have
the OU field in.

Formally, BR OV guidance applies to server certs, not SMIME personal certs,
but I guess that most providers will sunset OU for both at the same time,
if they depend on the same validation. Hence also your personal certs, if they
have an OU today, and are publicly trusted and/or issued by the same supplier
that gives you SSL certs, will be affected.

The change affects:
- those OV CAs that are (also) subject to CABF BR requirements (like the
InCommon IGTF Server CA)
- services, communities, and their relying parties that currently have a
credential with the OU field in it (attribute authorities, mostly, but
it may extend to client credentials as we talked about above)

My personal take is that OU was always rather ill-defined. The fewer elements
you have in a certificate, the less chance of "RS-style" random revocation.

Cheers,
DavidG.

--
David Groep

** Nikhef, Dutch National Institute for Subatomic Physics, PDP programme **
** Visiting address: Science Park 110 room D1.09, NL 1098 XG Amsterdam NL **
** Phone: +31 20 5922179, keybase.io: dlg, Signal: +31646812179 **
** PGP: 0xD80134C2 308E076A FP: 2facebea12803ba145685a21d80134c2308e076a **

[Angelo Santos]

Dear all,

Getting back to this discussion... and sorry if it is indeed a stupid
question...

Here in ANSPGrid CA we have the following formats for users and servers:

    /C=BR/O=ANSP/OU=ANSPGrid CA/OU=People/CN=subject-name
    /C=BR/O=ANSP/OU=ANSPGrid CA/OU=Services/CN=host/host-dns-name

So I'm wondering if there would be any problem related to deprecating
organizationalUnitName (OU).

    Regards,
    ---
    Angelo Santos

[Derek Simmel]

Angelo,

I think the problem is mainly for those CAs that rely on a commercial CA to operate, where that commercial CA is obligated under CA/B Forum rules to stop issuing certificates with an OU field after September 1, 2022.

Since you are running your CA with your own infrastructure, your CA can continue to issue certificates as you wish. As long as your relying parties accept your CA and have the trust chain installed to validate certificates issued by your CA, things should continue to work as they have done before without changes.

If you want to change your certificate fields to be compliant with the CA/B Forum rules, you would remove the OU field from your certificate subjects. IGTF does not require you to do this. Given the way your CA's issued certificates' subjects are formatted, you would still be able to differentiate user certificates from server certificates easily without the OU field. If you do make the change, you would need to update your CP/CPS accordingly.

- Derek

---
Derek Simmel
Pittsburgh Supercomputing Center
dsi...@psc.edu
+1 (412) 268-1035

[Angelo De Souza Santos]

Hi Derek,

Thank you for your detailed explanation. I was worried about, but fortunately no change is needed.

   Best Regards,

   ---

   Angelo Santos