Hi, I recently noticed that a lot of leaf certificates [0] have organizationalUnitName specified without other organizational information such as organizationName. Many times this field is used for branding purposes, e.g. "issued through <someone's kpi manager>" or "SomeBrand SSL".
BR v1.6.6 ยง 7.1.4.2.2i has guidance on usage of the OU field: "The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, , subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1." As the organizationName and other related attributes are not set in many of those certificates, even though e.g. "COMODO SSL Unified Communications" is a very strong reference to Sectigo's ssl branding & business, I believe the referenced certificate is not issued in line with the BR. Is the above interpretation of BR section 7.1.4.2.2i correct? - Matthias [0] please find attached 3 files which contain a query on the crt.sh database, with their results ( queried 2019-10-30T10:00:00Z and T12:00:00Z ) The queries count certificate IDs in the range 1890000000 ... 1900000000 (10M possible certificate IDs), and are filtering certificates which have an organizationalUnitName <> 'Domain Control Validated', but not the organizationName field: - cert_no_dcv: Total count count of the filtered certificate_ids - cert_by_issuer_no_dcv: Counted, grouped by issuer ID. This can contain duplicate counts, but only due to multiple issuer_ca_ids per certificate, which should not exist. - cert_by_issuer_name_no_dcv: Counted, grouped by issuer & organizationalUnitName: Certificates may be counted twice here due to multiple OU entries for one certificate. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
