May 2020 CA Communication

SUB ITEM 4.2: Byte-for-byte Identical Issuer and Subject Distinguished Names The proposal is to add the following text to section 7.1.4.1 of the BRs: “The encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.” And “The encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Name can be compared as equal according to RFC 5280, Section 7.1.” Note: This item is also being tracked in regards to directly updating Mozilla's Root Store Policy via https://github.com/mozilla/pkipolicy/issues/213.
SUB ITEM 4.2 DATE
SUB ITEM 4.2 COMMENTS

CA Owner Response Response Response
AC Camerfirma, S.A. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Actalis All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Amazon Trust Services All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Asseco Data Systems S.A. (previously Unizeto Certum) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Atos All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Autoridad de Certificacion Firmaprofesional Our CA should be able to implement this for certificates issues on or after the date specified below. 2021 Jun 30 Additionally from Firmaprofesional’s root it is hanging the CA “AC Firmaprofesional - CUALIFICADOS” (https://ccadb.force.com/001o000000nTKbUAAW) with two certificates, both of them disckoused: https://ccadb.force.com/001o000000nTKbUAAW (1) and https://ccadb.force.com/0011J00001LIWxrQAH and https://ccadb.force.com/0011J00001LIWxrQAH (2). This CA is intended to issue qualified certificates pursuant eIDAS for electronic signature (natural persons) and electronic seals (legal persons) and NOT website certificates of any kind. The encoding of the subject’s commonName of the root CA is UTF8. The encoding of the issuer’s commonName of (1) is printableString and the encoding of the issuer’s commonName of (2) is UTF8. So for (1) Firmaprofesional does not have a “Byte-for-byte Identical Issuer and Subject Distinguished Names”. Although the “AC Firmaprofesional - CUALIFICADOS” certificate that we are disclosing is (2) (see crl.firmaprofesional.com/cualificados.crt, which is the URL in our AIA leaf certificates field, for the issuing CA), (1) is quite spread, so it would take a while to substitute any instance of (1) in all of our clients and relying parties, and we never would be certain that all of them have been replaced.
Buypass All of our currently valid intermediate and end-entity certificates already comply with this requirement.
China Financial Certification Authority (CFCA) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Chunghwa Telecom All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Cybertrust Japan / JCSI All of our currently valid intermediate and end-entity certificates already comply with this requirement.
D-TRUST All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Deutsche Telekom Security GmbH All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Dhimyotis / Certigna All of our currently valid intermediate and end-entity certificates already comply with this requirement.
DigiCert All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Disig, a.s. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
E-Tugra All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Entrust All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
GlobalSign nv-sa All of our currently valid intermediate and end-entity certificates already comply with this requirement. For the 2nd part of this requirement, we understand its implied scope is within same issuer.
GoDaddy All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Google Trust Services LLC All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Government of Hong Kong (SAR), Hongkong Post, Certizen All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Government of Taiwan, Government Root Certification Authority (GRCA) Other (please describe below) GRCA and its sub CAs do not issue any TLS certificates since 18-Seepteember 2019, and we will revoke all TLS certificates on 7/19/2020. Our root cert will be removed from Mozilla's root store after 7/19/2020 Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=1463975
Government of The Netherlands, PKIoverheid (Logius) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
HARICA Other (please describe below) We probably comply with this requirement but we would need time to analyze our certificate corpus to make a final determination. In any case, we can comply with this requirement if need be and can implement within 1 month once decided.
IdenTrust Services, LLC All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Internet Security Research Group All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Izenpe S.A. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Krajowa Izba Rozliczeniowa S.A. (KIR) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Microsec Ltd. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
NETLOCK Kft. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
OISTE All of our currently valid intermediate and end-entity certificates already comply with this requirement.
QuoVadis All of our currently valid intermediate and end-entity certificates already comply with this requirement.
SECOM Trust Systems CO., LTD. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
SK ID Solutions AS Other (please describe below) Please note that SK has terminated issuance of TLS Server Certificates as of September 1st 2017 and therefore we are unable to meet this requirement. The last TLS certificate will expire in September 2020.
SSL.com Other (please describe below) We would need some time to review our population of issued certificates and check whether we are currently compliant. Notwithstanding any issues, we should be able to comply with this requirement within 1 month after this is determined.
Sectigo All of our currently valid intermediate and end-entity certificates already comply with this requirement.
SecureTrust Other (please describe below) All valid SecureTrust intermediate certificates already comply with this requirement. We have raised our concerns with the second clause of this requirement on the CA/B Forum servercert-wg thread here: https://oldportal.cabforum.org/pipermail/servercert-wg/2020-May/001873.html The second clause, as written, places restrictions on end-entity certificates such that two end-entity certificates whose subject DN differ only by case (e.g., two end-entity certificate with subject DNs of "/CN=example.com" and "/CN=EXAMPLE.COM") would be non-compliant. This serves no useful goal and is most certainly not an existing Root Program requirement. It appears that this problematic language will be corrected (https://oldportal.cabforum.org/pipermail/servercert-wg/2020-May/001906.html), but the original language is quoted in this Mozilla Survey, so we wanted to point it out again. More generally, the second clause does not accomplish the stated goals of mandating byte-for-byte equal DNs for CRLs and OCSP, and it also suffers from a corner case presented by code points newer than Unicode 3.2 (https://oldportal.cabforum.org/pipermail/servercert-wg/2020-May/001917.html). In light of this, we would be supportive of alternative language which places such restrictions on CRL issuer DN and OCSP encoding as well as addresses the Unicode 3.2 corner case.
Shanghai Electronic Certification Authority Co., Ltd. All of our currently valid intermediate and end-entity certificates already comply with this requirement.
SwissSign AG All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Taiwan-CA Inc. (TWCA) All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Telia Company All of our currently valid intermediate and end-entity certificates already comply with this requirement. 2020 Jun 1 Confirmed from our CA vendor.
TrustCor Systems All of our currently valid intermediate and end-entity certificates already comply with this requirement.
Trustis Other (please describe below) End-entity certificate issuance under the current service has been discontinued.
Web.com All of our currently valid intermediate and end-entity certificates already comply with this requirement.
certSIGN All of our currently valid intermediate and end-entity certificates already comply with this requirement.
eMudhra Technologies Limited All of our currently valid intermediate and end-entity certificates already comply with this requirement.