Has this already been done in staging? While I agree that the change shouldn't break anything, weirder things have happened. Is there any good way to test that applications will continue to work before the change takes effect? (Especially for those use cases that don't involve web browsers, like API calls, client auth, SMTP, and other non-HTTP protocols.) Do other common CAs already not include this data?
Thanks. Just being nosy; I don't actually anticipate any problems directly affecting me, but it'd be good to have resources for people to use in case people think it might affect them.
I had a short look into the X509v3 Certificate Policies and, oh my, this is confusingly worded in many places (especially the BRs).
As I understand it, the Certificate Policies (2.5.29.32) extension itself is mandatory for TLS leaf certificates. It must include at least one policyIdentifier entry. This is either 2.23.140.1.2.1 (domain-validated certificate), 2.23.140.1.2.2 (OV cert), or 2.23.140.1.1 (EV cert). You will find this in all BR compliant certificates.
Next, with the current BR version, CAs may add additional policyIdentifiers to their certificates. This is now purely optional (but not discouraged) it seems. Each policyIdentifier can optionally have one or more policyQualifiers. For policyQualifiers, the (current) BR's only allow id-qt-cps (1.3.6.1.5.5.7.2.1), which is a URL to a CPS. These policyQualifiers are now discouraged.
I understand that Let's Encrypt wants to remove their custom policyIdentifier they use for the CPS and the corresponding policyQualifiers (the CPS link).
I didn't look too deep into other CAs, but it appears that up until recently CAs have typically used the policyQualifiers field:
ZeroSSL (Sectigo) issuer ZeroSSL RSA Domain Secure Site CA includes both a custom policyIdentifier and a corresponding policyQualifier (example cert)
Buypass issuer Buypass Class 3 CA 2 includes not only a custom policyIdentifier, but also includes its CPS (policyQualifier) twice, in both the reserved and the custom policyIdentifier (example cert).
The Google Trust Services issuer GTS CA 1P5 appears to include a custom policyIdentifier, but without any policyQualifiers (example cert). During my quick check, this was the only CA without a policyQualifier, but like I said, I haven't looked in greater detail.
I would also like to remind Let's Encrypt that they should reflect the change (when it's made) in their CPS, since it explicitly mentions the custom OID and the CPS link as being part of the subscriber certificate.
To be clear, the change here is about the certificate that Let's Encrypt gives you. There isn't any change I'm aware of to how Let's Encrypt reads the CSR you send it, and as far as I understand it, it only picks out the couple pieces it uses from that CSR and ignores the rest.