January 2018 CA Communication

ACTION 2: Disclose Use of Methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation On 19-December, significant concerns were raised about the reliability of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. Since then, discussions on the CA/Browser Forum Public list have resulted in a proposed ballot to prohibit the use of these methods after 1-August 2018. Rather than accept the risk of continued use of these methods, Mozilla may decide to set an earlier deadline such as 1-March 2018. If your CA uses either of these methods, please evaluate your implementation for vulnerabilities, follow the discussion closely, and be prepared to quickly discontinue your use of these methods of domain validation. Please select the correct response for your CA:
ACTION 2 COMMENTS (please include any exceptions to the response you selected above)

CA Owner Response Response
AC Camerfirma, S.A. We have no valid certificates that were issued using these methods.
Actalis We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. Regarding method #1: Our implementation of this method requires verification that the Applicant correspond not to just any "Contact" of the domain (as allowed by method 1), but rather to the Registrant. Furthermore, the request is authenticated not by contacting the Applicant Representative directly (as allowed by method 1), but rather by contacting an appropriate Applicant department (e.g. purchase dept., human resources, IT operations, etc) and verifying with this latter that the Representative actually is a known and authorized person. Regarding method #5: Our implementation of this method requires that the Domain Authorization Document be issued by the Domain Registrar. Overall, we have used this method very seldom. It should also be noted that, to date, most of the certificates issued by Actalis are issued to organizations that our salesmen know personally, and that the authorized Applicant Representatives are, normally, specified in advance by the Applicant as part of a formal purchase order. We are highly confident that all the certificates we have issued so far have been issued to the right persons.
Amazon Trust Services We have no valid certificates that were issued using these methods.
Asseco Data Systems S.A. (previously Unizeto Certum) We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. This methods are only used if CERTUM authenticates the Applicant's identity under BR Section 3.2.2.1 and the authority of the Applicant Representative under BR Section 3.2.5. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the end of March, 2018.
Atos We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. No findings.
Autoridad de Certificacion Firmaprofesional We have no valid certificates that were issued using these methods.
Buypass We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We do not use method #5. We use method #1 for OV/EV only as described in the BR Self Assessment. We support a limited geographical area in northern Europe and use only governmental controlled registries for validating the organization information (identity and address). We require a perfect match between this trustworthy organization information against (self asserted) Domain Name Registrant information. The match is based on comparing either organization name and organization number or organization name and organization address. If this match fails, we use another method. We do not allow the use of Applicant's Parent Company, Subsidiary Company, or Affiliate for the purpose of domain validation. We have not identified any vulnerabilities in our procedures or implementation using method #1 as described.
Certicámara None of our root(s) are enabled for websites (SSL) in Mozilla products.
Certinomis / Docapost We have no valid certificates that were issued using these methods.
China Financial Certification Authority (CFCA) We have no valid certificates that were issued using these methods.
Chunghwa Telecom We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. For some of our SSL application cases, we are also the regtstrar of the Base Domain Names. Therefore, for these cases, our method already complies with the proposed method 12 in CA/Browser Forum ballot 218. However, we are not the regtstrar of the Base Domain Names for all of our application cases. For those cases where the applicant is itself the Domain Contact, we verified the identity of the applicant in accordance to BR 3.2.2.1. Especially, we verified the identity and address of the applicant by using the QGIS (Qualified Government Information Source) and QTIS (Qualified Tax Information Source). In addition, we checked the registered seal of the company. For those cases where the applicant is not the Domain Contact itself but is authorized by the Domain Contact to apply for the SSL certificate, we verified the identity and address of the applicant by using the QGIS (Qualified Government Information Source) and QTIS (Qualified Tax Information Source) and also checked the registered seal of the company. In addition, we required the applicant must present a Domain Authorization Document that came from the Domain Contact. We do not think there are any problem, because Taiwan government provide the QGIS (Qualified Government Information Source) and QTIS (Qualified Tax Information Source) as Open Data and the seal registration systems for organizations and individuals have been well-established. Although, we do not think there are any problem, still we will take thorough review on all the cases of our active (not expired or revoked) SSL certificates there is no any mistake. Due to the incoming Holiday for Chinese New Year, we hope we will finish the review and report our findings on the mozilla.dev.security.policy list by March 5. Our company will have a person to join CABF validation working group meeting and Face to Face meeting from March 6 to March 8 to discuss with Mozilla and other members or experts about the validation of domain name ownership and control of OV/EV SSL certificates.
ComSign We have no valid certificates that were issued using these methods.
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We use both methods at the same time so the risk of both at the same time fail is minimum. We only issue SSL (and) EV certificates to Government and all the personal data related with the domains is stored and validated in different databases for the use of the public administration, such as MUNICAT (http://municat.gencat.cat/ca/inici/). Given that we sincerely think that we are not in risk due to the weaknesses of these two method
Cybertrust Japan / JCSI We have no valid certificates that were issued using these methods.
D-TRUST We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We had no findings. Of course we follow the current discussion in the CAB forum on the security of this validation method. We take the security concerns mentioned there very seriously and are working on a further and continuous improvement of our procedures within the framework of the Baseline Requirements. D-TRUST issues no DV certificates, so that our applied validation process is always significantly more extensive than the sole application of this methods.
Dhimyotis / Certigna We have no valid certificates that were issued using these methods.
DigiCert We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. DigiCert has active certs that used these methods from the Symantec transition and the DigiCert systems. However, DigiCert is in the process of stopping the use of these methods for routine validation due to the identified security issues. We anticipate that this report will be ready and disclosed on mozilla.dev.security.policy by April 15, 2018. We are removing both methods from our CP/CPS to align with results of that report and this decision.
Disig, a.s. We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We are using methods 3.2.2.4.5 with combination with the methods 3.2.2.4.3 and also the applicant or the person act behalf of applicant shall personally come to the CA. It should be a representative of legal person which is listed as a domain owner or person who is listed as domain contact.
DocuSign (OpenTrust/Keynectis) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. The verification is only performed by a human; we require the presentation of a company registration document corresponding to the domain holder, the signature of a representant of this company granting the issuance of the certificate for the requested domain, and a copy of an official identity document of this person.
E-Tugra We have no valid certificates that were issued using these methods.
EDICOM We have no valid certificates that were issued using these methods.
Entrust We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We have reviewed our practices for the implementation of BR 3.2.2.4.1. We are satisfied that our practices confirm identity, domain ownership and authorization to issue a certificate. We do see that it is possible for there to be two organizations with the same name. The result could be that one organization could falsely claim ownership of a domain. This vulnerability can be mitigated by also verifying the domain registrant by name and another unique identifier.
Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. GDCA has never used BR 3.2.2.4.1 for domain validation. However, our CP/CPS has disclosed that we use BR 3.2.2.4.5 as part of the domain validation, and after checking all the SSL certificates issued by GDCA, we found a total of 9 active (not expired or revoked) certificates issued using BR 3.2.2.4.5, and for 7 of those certificates, we contacted our customers and re-validated the domains using BR 3.2.2.4.4 and 3.2.2.4.6, and we revoked the rest 2. In the meantime, we stopped issuing certificates using BR 3.2.2.4.5 as of 31 January 2018, and will remove this domain validation method in the next version of our CP/CPS, which are expected to be released in April 2018.
GlobalSign We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. GlobalSign makes use of method 1 for OV/EV certificates to validate domains of certain customers as follows: - Establish the identity of the Applicant entity organization named in the certificate request following BR Section 3.2.2.1 for OV/ EV Section 11.2 - Information is compared to the domain contact in public Whois records - Match the Applicant’s name and country to the information provided in the Whois records - GlobalSign uses a QGIS, QTIS, QIIS to contact the Applicant as described in BR requirements We stand by our current process for method 1. However we are ready to cease this method and use other allowed methods following the effective date in ballot 218 v2.
GoDaddy We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218. We are using 3.2.2.4.12 and conform with ballot 218. CP/CPS is being updated to reflect this by April 1st.
Google Trust Services LLC (GTS) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. Google Trust Services uses the method in section 3.2.2.4.1 BR for the internal issuance of OV certificates to its affiliate companies. We followed the discussion regarding this method closely and have reviewed our implementation both internally and with our auditors. We found that the raised vulnerabilities do not apply in the particular context in which we use the method. We are planning to migrate away from this method and replace it with one of the robust and more automatable methods in section 3.2.2.4 BR.
Government of Hong Kong (SAR), Hongkong Post, Certizen We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. All our SSL certificates are OV certificates. With respect to the validation of domain authorization, we make use of publicly available records from Domain Name Registrar, such as WHOIS or other DNS record information, to validate the applicant's ownership or control of each FQDN. Actually additional steps are required in our implementation of this method such that our requirements of domain authorization is no less than that required by Domain Name Registrar.
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) We have no valid certificates that were issued using these methods.
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. We expect to report our findings by the end of April, 2018.
Government of Taiwan, Government Root Certification Authority (GRCA) We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218.
Government of The Netherlands, PKIoverheid (Logius) We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. 16/3/2018
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We are providing OV SSL (Organization Validated SSL) certificate to government agencies of Republic of Turkey. Authentication of government agencies having requested OV SSL certificate from Kamu SM shall be performed by way of verification from official correspondences made between Kamu SM, relevant government agency and relevant channels of domain ownership. We use “nic.tr” which is the government entity that keeps “.tr” top level domain in Turkey. This validation method is under BR Section 3.2.2.1. In addition, Kamu SM requests change on a page submitted in the domain name to test the agency’s control over the domain name. The requested change is the publication of the request token which will be generated from the information used in certificate signing request by the government agency, in the file which is served at .well-known/pki-validation/ directory and named as “kamusmdv.txt” on the domain. This validation method is under BR Section 3.2.2.4.6. Since we use two methods of domain authorization validation and we are responsible only issuing certificates to government agencies, we do not think we will encounter any problems with domain verification. However we analyzed our implementation and analyses show that there are no vulnerabilities.
HARICA We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218.
IdenTrust Services, LLC We have no valid certificates that were issued using these methods.
Internet Security Research Group (ISRG) We have no valid certificates that were issued using these methods.
Izenpe S.A. We have no valid certificates that were issued using these methods.
Krajowa Izba Rozliczeniowa S.A. (KIR) We have no valid certificates that were issued using these methods.
LuxTrust We have no valid certificates that were issued using these methods. We do not currently commercialize OV/EV SSL certificates, we have only generated those certificates for test purposes.
Microsec Ltd. We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We follow the same identification rules to validate the identity of the Applicant and the domain owner which are used for the qualified certificates required by eIDAS. These rules are mainly based on and similar to the methods described in section 3.2.2.4.1 and 3.2.2.4.5 of BR but they are much safer. The identity validation of the Applicant usually happens through F2F meeting which is much better than a fax or e-mail based validation. As part of the validation process we check the validity and the content of the personal ID document of the Applicant, which is validated also on-line against the official database of the Ministry of Interior. The validation of an Organization is based on the official on-line company registration information service operated by the Hungarian Company Registration Court, which gives digitally signed proof of the actual registration status and the registered data of all the Hungarian companies. Similar on-line information service is available for all the EU Member States. We mainly issue SSL certificates for Hungarian Applicants, and we don't issue certificates for domains outside of the EU. We strongly believe that our validation methods are safe enough and we hope that after closing the discussion in the CABF Validation Group these validation methods will be revised and will be allowed again with stronger and more precise requirements. We will continue to use these methods but to fulfil the new requirements of the BR and Mozilla we decided to introduce more validation methods above the used methods. As a result of this we always will use more than one method for the validation and at least one of them will be selected from the actually allowed validation methods. We plan to use the methods from 1 to 6, but presently we don't plan to introduce the methods from 7 to 12. We plan to publish our new CPS in April 2018, which will describe our validation methods more precisely than our present CPS. Our present CPS allows us to use other validation methods as an extra above the specified methods so we are able to start using this new methods before issuing our new CPS.
NetLock Ltd. We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218. Because of the eIDAS and the connected national laws we have extended those verifications. The Act CCXXII of year 2015: Section 82 (1) A certificate issued by a trust provider must contain the right, validated information, unless it is apparent from the certificate itself that the authenticity of the data has not been verified by the trust provider (especially in the case of an pseudonym). For this purpose, the trust provider must verify the data to be included in the certificate, and in particular verify the identity of the certificate subject, the authenticity of the identification data and, if applicable, the identification data corresponds to governmental or central databases, the right of representation of the Applicants Representative, the right of representation to be included in the certificate, the right to dispose of the certificate domain, the right to dispose of the IP address to be included in the certificate, the existence of the organizational unit to be included in the certificate, in the case of profession, the right to exercise it. (2) In the case of qualified trust services, the trust provider shall verify the identity as provided for in Article 24 (1) of the eIDAS Regulation by considering that a requirement under national law under the eIDAS Regulation referred to in paragraphs 3 to 8 obligations. In the case of a non-qualified trusted service, the trust provider shall check the identity in accordance with the methods referred to in Article 24 (1) of the eIDAS Regulation and under the obligations set out in paragraphs 3 to 8, in accordance with Article 24 (1) (c) of this Article may accept an electronic signature or electronic stamp with a high degree of security beyond the certification of a qualified electronic stamp. (3) If the trust provider wishes to verify the identity of the natural person's certificate holder on the basis of personal presence or equivalent identification, the Act LXVI of 1992 on the registration of citizens' personal data and address, (hereafter referred to as "Nytv." on the basis of an official identity card for the purpose of verifying identity.) (8) If the subject of the certificate is not a natural person, the trust provider shall verify at least the full name and unique identifier of the certificate subject contained in the certificate. If the subject of the certificate is a registered person in Hungary, the Trust Provider verifies the authenticity and validity of these data on the basis of the authenticated records or, if no such public records exist, on the official record of the registration, otherwise the verification shall be governed by paragraph 5. (9) If, on behalf of the subject of the certificate, the representative of the Applicant acts, or the certificate includes a full or partial representation right or a legally binding legal status (hereinafter: the right of representation), the trust provider shall, before issuing the certificate, on the basis of statutory, public records, instruments of incorporation or, in the absence thereof, authorization, to establish the existence of the right and the content of the certificate in the certificate and to record the results of the validation. This means in the case of 3.2.2.4.1 we use the Registrant data and validate following the 3.2.2.4.1 1) and look after the company in governmental database. (section (8)) This query gives us the Principal, and if not he/she requests the certificate in the name of Applicant, we need Authorization document. (section (9)) In the case DAD (3.2.2.4.5) we are also checking the right of the authorization too in the same way. We are preparing to drop these authentication methods in the future.
OISTE We have no valid certificates that were issued using these methods.
QuoVadis We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. March 1
SECOM Trust Systems CO., LTD. We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. The following was sent on January 10, 2018 from our colleague to public@cabforum.org. In our understanding, we are using 3.2.2.4.1 and .5 in our validation process. We understand that checking the domain with 3.2.2.4.1 or .5 is insufficient to see if an applicant has control over a domain. It is agreeable for us to confirm control over a domain by obtaining a change on a targeting domain. We might choose to move over time to some of other the methods, but they may not be appropriate in all case. In addition, we had used 3.2.2.4.1 and .5 for long period, and procedures (including audit) have been carried out on that premise. Therefore, we think that 3.2.2.4.1 and 5 cannot replace within short period. To be more precise, we believe that 3.2.2.4.6 to .10 should be done with automation, and should require following concern. - Judgment for the automated system to be valid - How to keep logs and audit trails in an automated system - Explain to the audit firm that the system and log are valid In addition, in Japan audit firms, inquiries to the home country are prone to occur, and we usually cannot estimate lag for their answer. Furthermore, we will take some time to create internal documents (including documents for audit) after their answer. We need to discuss the change to major customers after the above adjustment. As mentioned above, 3.2.2.4.1 and .5 are methods that have been used for many years, and it is conceivable that the business flow of large customers is also built on these assumptions. Therefore, we think that a period to review the flow is also necessary.
SK ID Solutions AS We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218. Method 3.2.2.4.1 regarding OV certificates did not apply to us, because we have stated in our policy https://sk.ee/upload/files/SK-CP-TLS-EN-v5_0-20171130.pdf chapter 1.3.3, how the certificate request and subscriber was validated. Starting from September 1, 2017, SK ID Solutions no longer issues TLS Server Certificates (more information available at: https://sk.ee/en/News/sk-will-cease-issuing-tls-server-certificates).
SSL.com We have no valid certificates that were issued using these methods. Our CP/CPS (version 1.3) allows for use of these methods. However, we have never employed either method as part of certificate issuance, and shall only employ these methods with appropriate mitigation for the known vulnerabilities of each method.
Sectigo We have no valid certificates that were issued using these methods.
SecureTrust We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. Trustwave has no active certificates issued using BR method 3.2.2.4.5 and our CPS states we do not use this method. Trustwave does have active certificates issued using BR method 3.2.2.4.1. As our CPS states, this method is only used for OV and EV certificates, and not used for DV only certificates. Our validation procedures require a full match on the organization name and address between the WHOIS record for the domain and the data source for the organization before we will issue the certificate. The additional validation needed for OV and EV certificates, offers additional mitigations to the vulnerabilities mentioned. We do not have any findings to report. Trustwave is following the discussions on public lists regarding the use of these methods. And, Trustwave will work to use only the other approved methods within the time frame Ballot 218 has put forth.
SwissSign AG We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below. Until now our analyses does not show any vulneralility. How ever will contninue to review our implementation and we will report our findings Mid of March 2018
Swisscom (Switzerland) Ltd None of our root(s) are enabled for websites (SSL) in Mozilla products.
T-Systems International GmbH (Deutsche Telekom) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We have not found apparent vulnerabilities in our use of these methods.
Taiwan-CA Inc. (TWCA) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We are not only use 3.2.2.4.1 and 3.2.2.4.5 but also use 3.2.2.4.3 / 3.2.2.4.4 to validate domain authorization control. The applicant must provide the proof evidence that the domain is own by the organization.
Telia Company (formerly TeliaSonera) We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. Telia would like to continue using methods 3.2.2.4.1 or 3.2.2.4.5 for Domain Validation with improved process which also enables delivery of OV certificates. Telia concern is to find an alternative method to replace 3.2.2.1 and 3.2.2.5 in such tight schedule and therefore strongly proposes to not prohibit these methods prior 1st of August 2018. Telia CA targets in Nordic countries where each company has a unique business ID and official address, which are available from national company registers. Most domain registrar fields contains both of these fields. In validation step national company registers and domain registrar information are verified in addition with other validation steps. Telia believes the followed process makes the suggested attack vectors hard to utilize against Telia used validation process. Current Telia CA process validates the company using detailed information stored in national company registers including unique Business ID and address. The information is compared against domain registrar. Telia also checks requester represents the verified company by calling to company PBX which redirects the call to the requester. Alternative this could be done by checking requester phone number is registered to the Company from reliable public phone register.
TrustCor Systems We have no valid certificates that were issued using these methods. TrustCor has discontinued use of 3.2.2.4.1 effective 23rd January 2018; our next CP and CPS will formalise this policy decision. The self-assessment report will say that we no longer use 3.2.2.4.1. There are no valid certificates in operation today which used it as a validation method. TrustCor has never used 3.2.2.4.5 to validate domain control/ownership, and the current CPS states this.
Trustis We have active (not expired or revoked) certificates issued using BR 3.2.2.4.1, but we only use this method in a way that already complies with the proposed method 12 in CA/Browser Forum ballot 218.
Visa We have active (not expired or revoked) certificates issued using these methods. We will review our implementation for vulnerabilities and report our findings on the mozilla.dev.security.policy list by the date specified in the comments section below.
Web.com We have no valid certificates that were issued using these methods.
certSIGN We have active (not expired or revoked) certificates issued using these methods. We have reviewed our implementation for vulnerabilities and have reported our findings below. We have reviewed our implementation and we didn't identified any vulnerabilities.