Questions re: CPS URL and OID will not be included

Issuance Policy
1

Just some questions about this announcement:

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.

9 Likes
2

Good point! It has not yet been made in staging but we will do that first, probably with next week's deploy.

9 Likes
3

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.

9 Likes
4

Thanks! We’re already planning to have the CPS updated before we go live. (Changes: Remove CPS OID and URL from Subscriber Certificate profile by aarongable · Pull Request #191 · letsencrypt/cp-cps · GitHub)

9 Likes
5

This change is now live in staging, as of about 5 minutes ago.

8 Likes
6

Thank you; are there any changes to be made to Pebble for testing this? Or do Pebble certificates already not include these fields?

5 Likes
7

Pebble certs already do not contain any Certificate Policy extensions.

7 Likes
9

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.

7 Likes
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.