In the major certificate profile rework added to the TLS BRs in v2.0.0, a new category of CA certificate was created that is exempt from the current subject naming requirements for CA certs. These "Cross-Certified Subordinate CA Certificates" (see § 7.1.2.2) are intended to allow new cross-signs to be issued for existing CA keys where the original name no longer follows the current naming rules. They instead fall under the requirement "the encoded subject name MUST be byte-for-byte identical to the encoded subject name of the existing CA Certificate" in § 7.1.2.2.2.

Zlint is designed to do static analysis on a single signed artifact and doesn't have the context required to determine if a certificate is using the same key as an existing CA or if the subject matches the existing certificates for that key. One of the affected lints, e_subj_orgunit_in_ca_cert, implements this exemption by using the configuration system to let the user provide the context that the supplied certificate is intended as a cross-signed CA. (Though that lint marks cross-signs as passed, I'd argue it should probably be NA.) I also found e_ca_multiple_reserved_policy_oids which implements a similar exemption in a similar fashion.

I've found four more lints from before v2.0.0 that enforce older CA subject restrictions that have not yet been updated to handle this exemption and so incorrectly fail these certificates:

• e_ca_common_name_missing
• e_ca_country_name_missing
• e_ca_country_name_invalid
• e_ca_organization_name_missing

I'm currently thinking we can probably fix these lints along the same lines, but they have the added complication that the exemption only applies to new cross-signed CAs issued after 2023-09-15 whereas e_subj_orgunit_in_ca_cert has always had the exemption. Questions for the group: How have we typically handled requirements that have been narrowed after a date? Would having the CheckApplies() function also enforce the start of the exemption period when checking the configuration be acceptable or is that too hacky? Given that even new cross-signs MAY set their notBefore as early as "the earliest notBefore date of the existing CA Certificate(s)" does it even make sense to check the date? I suppose the issuance date could also asserted in the config to handle this.