1628720 - Add E-Tugra Root Certificates RSA v3 / ECC v3

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task, P2)

Description

[Davut Tokgöz]

Attachment: BR SelfAssesment V3.0_202003_v3.pdf

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

Steps to reproduce:

E-Tugra would like to add two new roots to NSS/Mozilla Root Store. Self-assessment checklist, CCADB Root Inclusion Case Numbers are 576, 577.

Comment 1

[Davut Tokgöz]

The Ceremony Report signed by Qualified Auditor is uploaded at https://e-tugra.com.tr/Portals/6/Download/EtugraRootCeromonyV3.pdf .

Comment 2

[Ben Wilson]

Questions to resolve include: corporate good standing, audit with SHA2 hashes of roots included, and test websites. Next step is to review BR self-assessment.

Comment 3

[Ben Wilson]

Here is the CCADB information for this inclusion request: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000576
Additional items need to be completed in the CCADB. Here is an initial list of “Needs”, for each of the roots (RSA and ECC):
1- An explanation of why the root certificate needs to be included in the root store
2- The unique function of each root, since the request includes multiple roots
3- A public URL through which each root certificate can be directly downloaded.
4- 3 test websites (valid, expired, revoked) whose TLS/SSL certificate chains up to each root.
5- A test of the valid certificate with http://certificate.revocationcheck.com/
6- Evidence of a lint test to verify that no certificates issued in each CA hierarchy violate any of the CA/Browser Forum Baseline Requirements (BRs) (e.g. https://github.com/awslabs/certlint )
7- Evidence of a test to verify that no certificates issued in this CA hierarchy violate the X.509 rules. (e.g. https://github.com/kroeckx/x509lint)
8- Successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
9- Description of PKI Hierarchy (URL and/or Description of each PKI Hierarchy).
10- Details related to any of PKI hierarchy check-boxes that are selected
11- Records in the CCADB for all existing intermediate certificates (https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data)
12- Constraints placed on any External SubCAs & RAs
13- Requested Mozilla-Applied Constraints, if any

Comment 4

[Davut Tokgöz]

Attachment: EVControl For RSA v3

Comment 5

[Davut Tokgöz]

Attachment: EVControl For ECC v3

Comment 6

[Davut Tokgöz]

All Missing parts are completed except item 7. It will be completed as soon as possible.
For Item 8, the screenshots is attached.

Comment 7

[Davut Tokgöz]

Hi
All missing parts are completed in CCADB records.

Comment 8

[Ben Wilson]

Never mind. I see that the BR Self-Assessment and the CPS match on methods under 3.2.2.4.

Comment 9

[Ben Wilson]

There are two items I'd like to see happen before I move this into the queue for CP/CPS Review--(1) the annual audit for 2020 should include the two new roots and (2) the CPS should be brought current with version 1.7.1 of the Baseline Requirements.

Comment 10

[Davut Tokgöz]

Hi
Etugra 2020 annual audit was completed on between Sep 21st-25th by LSTI. We will post it whenever audit letter is ready. We reported this delay on https://bugzilla.mozilla.org/show_bug.cgi?id=1659426.

Comment 11

[Davut Tokgöz]

Hi.
The Audit Letter was issued and placed on http://lsti-certification.fr/images/E-TUGRA__1646-170-AL-V4_SS.pdf .
We summited it on root inclusion case (576) in CCADB. But some errors existing when validation AL. Both Auditors and we could not solve them. Can you review the problem to pass AL submit phase?
Regards

Comment 12

[Ben Wilson]

These were fixed with version 5 of the attestation letter, but it is no longer located here:
https://lsti-certification.fr/images/E-TUGRA_1646-170-AL-V5_S.pdf

Comment 13

[Davut Tokgöz]

I notify the Auditor company. Please get it from https://e-tugra.com.tr/Portals/6/Documents/E-TUGRA-1646-170-AL-V.5_S.pdf until they fix it.

Comment 14

[Davut Tokgöz]

The the attestation letter can be downloaded from

• https://www.lsti-certification.fr/wp-content/uploads/2021/01/E-TUGRA-%E2%80%93-1646-170-AL-V.5_S-copie.pdf and
• https://e-tugra.com.tr/Portals/6/Documents/E-TUGRA-1646-170-AL-V.5_S.pdf

Comment 15

[Ben Wilson]

Attachment: e-Tugra_CPS_v.5.0_Review.xlsx

Comment 16

[Ben Wilson]

CPS Review for Compliance with CABF and Mozilla Requirements
Updated August 2021 to include BR v. 1.8.0 and Mozilla Root Store Policy v. 2.7.1
Based on e-Tugra's CPS, v. 5.0, dated 25-October-2021
https://e-tugra.com.tr/wp-content/uploads/2021/10/E-Tugra_SUE_v5.0_EN.pdf
APPLICABLE REQUIREMENTS and References from RFC 3647, the BRs, the MRSP, CCADB Policy, etc.	DETAILED ROOT PROGRAM REVIEW <br />Reviewer Comments
Baseline Requirements for TLS Server Certificates
1 INTRODUCTION
1.1 Overview Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and CA/Browser Forum Requirements, those Requirements take precedence.”	Need to fix - the current CP and CPS only say, "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents." The Baseline Requirements and other CABF documents need to "take precedence".
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
Annually update CP and/or CPS. (BR § 2)	Needs to be fixed - While section 9.12.1 states, "The “CPS” document and relevant practices are reviewed annually at the management review meetings." The CPS should say something like, "and a new version of the CPS is published annually, even if no other changes are made."
2.2. Publication of information - BR text "The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version." --> Copy the specific text that is used into the explanation in this row. (in English)	OK - Section 2.2 could be improved by stating that e-Tugra "adheres to the latest published version". Also, section 2.2 also says "other root store policies/programs where GlobalSign Root Certificates are embedded" - this appears to be a copy-paste error and should be fixed.
2.3. Time or frequency of publication "The CA SHALL ... annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Indicate your CA's policies/practices to ensure that the BRs are reviewed regularly, and that the CA's CP/CPS is updated annually.	Should fix - See above - The CPS should say something like, "and a new version of the CPS is published annually, even if no other changes are made."
3. IDENTIFICATION AND AUTHENTICATION
3.1 Naming Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.	Should be addressed - eTugra should add an explanation in its CP/CPS about its handling of Turkish IDN domain names.
3.2.2.1 Identity If the certificate will contain Subject Identity Information (e.g. OV certificates with name or address of an organization), then indicate how your CP/CPS meets the requirements in this section of the BRs.	OK - CPS section 3.2.2 says, "“e-tugra” verifies the identity and address of the Applicant using the procedures found in section 3.2.2.1 or section 3.2.3 of the Baseline Requirements. Only application from entities based on or located in Turkey are accepted for Premium(OV) SSL and CSC." But note that the BR Self-Assessment from March 2020 is in conflict by stating, "Address information is only accepted for EV certificates"
3.2.2.7 Data Source Accuracy The CA's CP/CPS must explain how the CA determines that a third-party data source is reliable. For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” (Additional criteria are found in BR § 3.2.2.7) For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.” (EVG § 11.11.5)	Need to fix - the CPS needs to state how the reliability of third party datasources and QIISes are determined by e-Tugra.
3.2.4 Non-verified subscriber information “All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.” (MRSP § 2.2.1)	Need to fix - section 3.2.4 of the CPS states, "Other fields such as “L”, “S”, and “O” that may appear in DN field of a certificate are also accepted as valid upon the declaration of the applicant and they take place in the content of the certificate." This is not allowed by the requirements.
3.2.5. Validation of Authority "[T]he CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request."	Need to fix - the CPS needs to state how reliable communication is established with the true applicant (so that an impostor cannot obtain a certificate).
3.3.1 Identification and authentication for routine re‑key For data re-use, see subsection 5 of MRSP § 2.1 and BR § 4.2.1.	Need to clarify how application information is reused. Section 3.3.1 of the CPS states, "For certificates of Standard(DV) SSLStandard(DV) SSL, Premium(OV) SSL, EV SSL and “CSC” and “EV SSL” there is no possibility to re-key or to renew." However, section 4.2.1 of the CPS states, "Re-use of validation information is limited to 398 days for Premium(OV) SSL, EV SSL CSC and EV CSC."
4. CERTIFICATE LIFE‑CYCLE OPERATIONAL REQUIREMENTS
4.1.2. Enrollment Process and Responsibilities The process must require 1. a certificate request, and 2. a Subscriber Agreement.	Need to fix - e-Tugra needs to mention that it requires submission of a "Certificate User Agreement" as part of its enrollment process.
4.3.1. CA Actions during Certificate Issuance Pre-issuance linting (Recommended Practices) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”	Should be addressed - eTugra should explain what it does to pre-check certificates before they are issued. Which lints are used?
4.3.1. CA Actions during Certificate Issuance It is presumed that for each precertificate a corresponding certificate exists. See Required or Recommended Practices. Therefore, CAs must have the means to provide OCSP and revoke the serial number for any precertificate.	Should be addressed - eTugra should explain what it does to make revocation possible for precertificates.
4.3.1 CA Actions during Certificate Issuance The backdating of a certificate's notBefore date to avoid a deadline, prohibition, or code-enforced restriction is a Problematic Practice.	e-Tugra should flag / disclose its policy regarding the backdating of certificates to avoid enforcement of new rules
4.9.1.1 Reasons for Revoking a Subscriber Certificate Your CA's CP/CPS' reasons and timeframes for revoking an end entity certificate must be consistent with the reasons and timeframes required by this section of the BRs (24-hour revocation for reasons 1 through 5, and 5 days for the second set of reasons 1 through 11).	Needs to be fixed - Subsection 4 of BR 4.9.1.1 requires revocation if "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);". That provision is missing from Section 4.9.1 of the CPS. Also, the word "aroused" should be replaced with another word when translating to English. Also, while section 4.9.5 of the CPS states, "For SSL and CSC, revocation requests received via written statement or email or phone or via online section of e-tugra web are taken into process immediately within the working hours and revocation process is completed within 24 (twenty-four) hours," e-Tugra should conduct a close review of section 4.9.1.1 of the Baseline Requirements to make sure that its practices will be compliant.
4.9.1.2 Reasons for Revoking a Subordinate CA Certificate Your CA's CP/CPS's reasons and timeframes for revoking subordinate CA certificates must be consistent with the reasons and timeframes required by this section of the BRs. (Revocation within 7 days for reasons 1 through 9).	Need to fix - Section 4.9.1.2 of the Baseline Requirements lists nine reasons to revoke a subordinate CA. The e-Tugra CPS lists only 8. e-Tugra should compare its list with the list in the BRs to ensure that its revocation practices remain compliant.
4.9.12 "CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." (MRSP § 6)	Needs to be fixed - There is a typo in the URL - https://helpdesk.e-tugra.com.tr/. Also, CPS section 4.9.12 does not make it clear how to establish key compromise (It currently says, "Reports to etugra for Key Comprise include: The private key itself. A valid email address so that confirmation of your problem report and associated certificate revocations will be sent."). This list of methods is incomplete because e-Tugra has a helpdesk portal. The actual helpdesk website does not have any "top level" links to SSL certificate revocation. However, it is good that CPS section 1.5.2 has a better URL - https://helpdesk.e-tugra.com.tr/submit_ticket and the form there allows a pull-down for "Sertifika İptali / Certificate Revocation". So the URL in section 4.9.12 needs to be fixed with the URL in section 1.5.2, and the proof-of-compromise methods need to be explained better.
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
5.3.7. Independent Contractor Controls Third parties performing information verification duties must meet the requirements of BR § 5.3.3.	Could be improved. Section 5.3.7 of the CPS should state that any third parties / independent contractors receive training and have sufficient knowledge and qualifications to perform the tasks to which they are assigned. See comments below too under EVG 14.2.1.
5.7.1. Incident and Compromise Handling Procedures Indicate how your CA meets the requirements of this section, including notifying Mozilla in the event of CA key compromise. MRSP § 7 states, “Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”	Need to fix - procedures in CPS section 5.7.3 need to include notification of Application Software Suppliers in the event of a key compromise or disaster that affects the ongoing security of the CA's private key.
7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1. Certificate profile CAs SHALL generate non-sequential Certificate serial numbers greater than 0 containing at least 64 bits of output from a CSPRNG. (MRSP § 5.2) Indicate how your CA meets the requirements of this section.	Needs to be fixed - The discussion of certificate serial numbers in CPS section 7.1.4 gives reference to CPS section 3.1.5, but this is not the same as the certificate serial number. For example, the serial number in a DV certificate would not be specified in section 3.1.5. Section 7.1.2 (or 7.1) should say that the certificate serial number is a non-sequential number greater than 0 containing at least 64 bits of output from a CSPRNG.
7.1.2.2.g Subordinate CA Certificate - Separate, EKU-constrained issuing CAs (MRSP § 5.3) Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. Also, it is important to distinguish CAs using the appropriate serverAuth or emailProtection EKU. (See Required or Recommended Practices)	Should fix - e-Tugra should consider updating its explanation in CPS section 7.1.2.2 to address how it uses EKUs in subordinate CA certificates. It is insufficient to only refer to BR 7.1.2.2 and RFC 5280.
7.1.2.3.f For TLS server certificates, either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present. id-kp-emailProtection MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present. (MRSP § 5.2)	Should fix - CPS section 7.1.2.3 says for Key Usage "Signing, key encipherment, data encipherment fields are set". However, key usage bits vary depending on which type of algorithms are used.
7.1.3.2 Signature AlgorithmIdentifier SHA-1 is prohibited (except in a very narrow exception case). (BR § 7.1.3.2.1) (MRSP § 5.1.3) (Also a Mozilla Forbidden Practice)	Should fix - CPS section 7.1.3 says, "Root certificates which are for generating subscriber certificates still have SHA-1 or SHA-256 algorithm." e-Tugra should specify the exact SHA1 root certificate that it is referring to and indicate when it intends to retire that root.
7.1.4.2 Subject Information - Subscriber Certificates CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in BR §§ 3.2.2.4 and 3.2.2.5. Subject attributes MUST NOT contain only metadata such as ‘.’, ‘‐’, and ’ ’ (i.e. space) to indicate that it is blank, etc.	Need to fix - CPS section 7.1.4 says "The following values are used on the fields of Standard(DV) SSL" - then it has values that are not allowed in DV certificates. Generally, the only values allowed are the SAN (verified FQDN) and the country code. E-Tugra also needs to carefully review the descriptions under "values are used on the fields of Premium(OV) SSL" and make sure that they are accurate. For instance, there is only the certificate serial number allowed, and the CN MUST be one of the SANs that has been verified in accordance with BR 3.2.2.4.
7.1.4.2.2 Subject Distinguished Name Fields (Common Name) If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).	Should fix - The CN can only be one of the SANs that has been validated.
7.1.6. Certificate Policy Object Identifier	Need to fix - CPS sections 1.2 and 7.1.2.3 need to be consistent.
7.1.6.4 Subscriber Certificates Certificates MUST contain "one or more policy identifier(s) that are specified beneath the CA/Browser Forum’s reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)."	Need to fix - the policy OIDs in CPS section 7.1.2.3 need to be updated to include all applicable CA/Browser Forum OIDs.
7.2 and 7.3 - All OCSP responses and CRL entries for Subordinate CA Certificates MUST include a meaningful reason code.	Need to fix - CPS needs to state that OCSP responses and CRL entries for sub CA certificates will contain a reason code.
7.2.2 CRL and CRL entry extensions The issuer name for the CRL should match the issuer name in the CA certificate byte-for-byte. See Potentially Problematic Practices.	Need to fix - The CPS needs to acknowledge that issuer names on CRLs must match the name in the issuing CA's certificate byte-for-byte.
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
Also indicate your understanding and compliance with MRSP § 3.1.3, which says: “Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA public key is no longer trusted by Mozilla's root store. This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs. Successive period-of-time audits MUST be contiguous (no gaps).	Please confirm this understanding.
8.2. Identity/qualifications of assessor Indicate how your CA meets the requirements of this section. (Mozilla has additional requirements - https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications))	Please review the wiki page on providing Auditor Qualifications and confirm your understanding.
9. OTHER BUSINESS AND LEGAL MATTERS
9.5 Intellectual Property Rights - E.g. “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” (MRSP § 3.3.3)	Should fix - The footer on the CPS states, "All rights are reserved" which is inconsistent with the grant of a Creative Commons license. See MRSP section 3.3.3. On the second page of the CPS (no page number) it states, "permission is granted to reproduce and distribute this Certification Practice Statement of e-tuğra on a nonexclusive, royalty-free basis, provided that ...." Therefore, instead of saying "All rights are reserved" the footer should say something like "Copyrighted in accordance with page ii" or whatever. Alternatively, e-Tugra could refer to the Creative Commons Attribution License 4.0 (which has some of the same language as in the CPS.
9.16.3. Severability In the event of a conflicting law, the CA shall include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements and must immediately notify the CA/Browser Forum.	Need to fix - Section 1 of the CPS says, "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents." This is not the same as specifying what is done when a national law prevents e-Tugra from complying with the CA/Browser Forum's requirements.
APPENDIX A – CAA CONTACT TAG These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.	Not applicable?
APPENDIX B - Issuance of Certificates for .onion Domain Names	Not applicable?
For CAs seeking enablement of Extended Validation
EVG 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.	Need to fix - See comment above regarding a conflict with local laws.
EVG 8.3 - the CA shall have a statement that it conforms to the current version of the EV guidelines and that in the event of any inconsistency, the EV guidelines take precedence.	Need to fix - The CPS must say that the EV Guidelines take precedence, not "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents."
EVG 9.2.4 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency.	Needs clarfication - CPS section 3.2.2 says, "If the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province or locality level, then this field is mandatory. Otherwise this field is not included." However, it does not clarify that an irrelevant state, province or locality is omitted. EVG section 9.2.4 says, "These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency."
EVG 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.	Need to fix- I could not locate where e-Tugra publishes its QIIS/QGIS sources, and I didn't see it here - https://e-tugra.com.tr/en/certificate-policy-and-practice-statement/.
EVG 9.2.5 and 11.2.1 - subject registration number: if the jurisdiction of incorporation or registration does not provide a registration number, then the date of incorporation or registration is entered in this field.	Should fix - Section 3.1.5 didn’t indicate what e-Tugra does if there is no company registration number.
EVG 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.	Need to fix - While CPS section 7.1.4 says that the address in the certificate is the "street address and number of the subject (optional)", verification of the physical location of the organization is required for EV even if it is not included in the EV certificate. Section 11.1.1 of the EV Guidelines requires verification of the Applicant’s physical existence (business presence at a physical address). This must be done in accordance with section 11.4 of the EV Guidelines. The e-Tugra CPS should explain how it establishes the street address and meets subsection 2.A. of EVG 11.4.1. Section 3.2.2 is not detailed enough. It says, "The name or the title, legal existence and physical existence of the legal entity which will take place in the certificate are verified according to the official documents of the country of residence of the applicant. " It also says "The address of the central office of the legal entity of the certificate applicant is verified according to the legal documents of the country of residence." But the address used to make a legal existence filing might be different than the street address where actual business takes place.
EVG 9.2.7 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information.	OK - In CPS section 3.1.5, eTugra states, the "OU contains the organizational unit or a trademark which is registered in Turkish Standards Institution." (But what does eTugra for trademarks in OU fields that are not registered in Turkey?)
EVG 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.	Not applicable? See these parts of the EV Guidelines. Does e-Tugra issue any certificates with registration references (e.g. for EU companies)?
EVG 9.2.9 - the CA shall not include any subject attributes except as specified in EVG § 9.2.	Need to fix - either section 3.1.5, 7.1.2.3, or 7.1.4 should say that for EV certificates no other subject attributes appear except those specified in section 9.2 of the EV Guidelines.
EVG 11.1.3 - CAs must publicly disclose Agency Information about the Incorporating Agency or Registration Agency.	Need to fix- I could not locate where e-Tugra publishes its QIIS/QGIS sources, and I didn't see it here - https://e-tugra.com.tr/en/certificate-policy-and-practice-statement/.
EVG 11.2.2(4) - principal individuals must be validated in a face-to-face setting.	Need to fix - CPS section 3.2.3 should say that principal individuals of EV type "Business Entity" are validated face-to-face.
EVG 11.5.1 - the CA must establish of verified method of communication with the applicant.	Need to fix - The CPS must explain how e-Tugra establishes a trusted communication channel with the true applicant/certificate subject. For instance, any fraudster could say that they are the authorized requester and provide the fraudster's own phone number for verification of the certificate request.
EVG 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 enumerated ways: “(1) existence for at least three years, ... (2) listed in either a current QIIS or QTIS; (3) Demand Deposit Account ... by receiving authenticated documentation ... directly from a Regulated Financial Institution; or (4) ... a Verified Professional Letter ....”	Need to fix - e-Tugra must explain how it meets the requirements of EVG section 11.6.1 (operational existence).
EVG 11.9 - the CA must verify the signature on the subscriber agreement and certificate request	Need to fix - e-Tugra must explain how it verifies the signatures and the authenticity of the certificate request. See comments made under EVG 11.5.1.
EVG 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.	Need to fix - e-Tugra needs to explain its processes to check the accuracy and reliability of QIISes.
EVG 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.	Need to fix - e-Tugra needs to state that it checks to see whether anyone (applicant, approver, signer) is on a denied persons list as a money launderer, terrorist financier, etc.
EVG 11.13, 14.1.3 and 16 - the CA must perform final cross-correlation and other due diligence based on the entire corpus of information and have multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance	Need to fix - e-Tugra needs to state that it conducts final cross-correlation and other due diligence based on the entire corpus of information and has multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance
EVG 11.14.3 - validation data cannot be reused after 397 days	Need to clarify how application information is reused. Section 3.3.1 of the CPS states, "For certificates of Standard(DV) SSLStandard(DV) SSL, Premium(OV) SSL, EV SSL and “CSC” and “EV SSL” there is no possibility to re-key or to renew." However, section 4.2.1 of the CPS states, "Re-use of validation information is limited to 398 days for Premium(OV) SSL, EV SSL CSC and EV CSC."
EVG 14.1.2 – an internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.	Need to fix - CPS section 5.3.3 should specifically state that Registration Officers receive an "internal examination related to the EV Certificate validation criteria outlined in the EV Guidelines."
EVG 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.	Need to fix - CPS section 5.3.7 should say that e-Tugra ensures that all third party EV contractors satisfy all training and skills requirements of section 14 of the EV Guidelines.

Comment 17

[Ben Wilson]

My comments are in the attached Excel spreadsheet and excerpted in previous Comment #16. Please feel free to ask for clarifications where needed.

Comment 18

[Davut Tokgöz]

Attachment: e-Tugra_CPS_v.5.0_Review_ETugraComments.xlsx

Dear Ben,
Thank you for analysis of our policy documents. We have updated our policy documents with your analysis and comments. We have published on our repository. The comments about our fixes are on the excel sheet.
The updated documents E-Tuğra Repository: https://e-tugra.com.tr/en/certificate-policy-and-practice-statement
CPS is on https://e-tugra.com.tr/wp-content/uploads/2022/01/E-Tugra_CPS_v5.1.pdf
CP is on https://e-tugra.com.tr/wp-content/uploads/2022/01/E-Tugra_CP_v5.1.pdf
Regards

Comment 19

[Ben Wilson]

CPS Review for Compliance with CABF and Mozilla Requirements
Based on e-Tugra's CPS, v. 5.1, dated 12-January-2022	https://e-tugra.com.tr/wp-content/uploads/2022/01/E-Tugra_CPS_v5.1.pdf
1.1 Overview Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and CA/Browser Forum Requirements, those Requirements take precedence.”	Need to fix - the current CP and CPS only say, "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents." The Baseline Requirements and other CABF documents need to "take precedence".	Fixed
Annually update CP and/or CPS. (BR § 2)	Needs to be fixed - While section 9.12.1 states, "The “CPS” document and relevant practices are reviewed annually at the management review meetings." The CPS should say something like, "and a new version of the CPS is published annually, even if no other changes are made."	Fixed
3.1 Naming Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.	Should be addressed - eTugra should add an explanation in its CP/CPS about its handling of Turkish IDN domain names.	Fixed
3.2.2.7 Data Source Accuracy The CA's CP/CPS must explain how the CA determines that a third-party data source is reliable. For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” (Additional criteria are found in BR § 3.2.2.7) For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.” (EVG § 11.11.5)	Need to fix - the CPS needs to state how the reliability of third party datasources and QIISes are determined by e-Tugra.	OK
3.2.4 Non-verified subscriber information “All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.” (MRSP § 2.2.1)	Need to fix - section 3.2.4 of the CPS states, "Other fields such as “L”, “S”, and “O” that may appear in DN field of a certificate are also accepted as valid upon the declaration of the applicant and they take place in the content of the certificate." This is not allowed by the requirements.	Fixed
3.2.5. Validation of Authority "[T]he CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request."	Need to fix - the CPS needs to state how reliable communication is established with the true applicant (so that an impostor cannot obtain a certificate.	Fixed
3.3.1 Identification and authentication for routine re‑key For data re-use, see subsection 5 of MRSP § 2.1 and BR § 4.2.1.	Need to clarify how application information is reused. Section 3.3.1 of the CPS states, "For certificates of Standard(DV) SSLStandard(DV) SSL, Premium(OV) SSL, EV SSL and “CSC” and “EV SSL” there is no possibility to re-key or to renew." However, section 4.2.1 of the CPS states, "Re-use of validation information is limited to 398 days for Premium(OV) SSL, EV SSL CSC and EV CSC."	Fixed
4.1.2. Enrollment Process and Responsibilities The process must require 1. a certificate request, and 2. a Subscriber Agreement.	Need to fix - e-Tugra needs to mention that it requires submission of a "Certificate User Agreement" as part of its enrollment process.	Fixed
4.3.1. CA Actions during Certificate Issuance Pre-issuance linting (Recommended Practices) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”	Should be addressed - eTugra should explain what it does to pre-check certificates before they are issued. Which lints are used?	Fixed
4.3.1. CA Actions during Certificate Issuance It is presumed that for each precertificate a corresponding certificate exists. See Required or Recommended Practices. Therefore, CAs must have the means to provide OCSP and revoke the serial number for any precertificate.	Should be addressed - eTugra should explain what it does to make revocation possible for precertificates.	OK
4.3.1 CA Actions during Certificate Issuance The backdating of a certificate's notBefore date to avoid a deadline, prohibition, or code-enforced restriction is a Problematic Practice.	e-Tugra should flag / disclose its policy regarding the backdating of certificates to avoid enforcement of new rules	Fixed
4.9.1.1 Reasons for Revoking a Subscriber Certificate Your CA's CP/CPS' reasons and timeframes for revoking an end entity certificate must be consistent with the reasons and timeframes required by this section of the BRs (24-hour revocation for reasons 1 through 5, and 5 days for the second set of reasons 1 through 11).	Needs to be fixed - Subsection 4 of BR 4.9.1.1 requires revocation if "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);". That provision is missing from Section 4.9.1 of the CPS. Also, the word "aroused" should be replaced with another word when translating to English. Also, while section 4.9.5 of the CPS states, "For SSL and CSC, revocation requests received via written statement or email or phone or via online section of e-tugra web are taken into process immediately within the working hours and revocation process is completed within 24 (twenty-four) hours," e-Tugra should conduct a close review of section 4.9.1.1 of the Baseline Requirements to make sure that its practices will be compliant.	OK
4.9.1.2 Reasons for Revoking a Subordinate CA Certificate Your CA's CP/CPS's reasons and timeframes for revoking subordinate CA certificates must be consistent with the reasons and timeframes required by this section of the BRs. (Revocation within 7 days for reasons 1 through 9).	Need to fix - Section 4.9.1.2 of the Baseline Requirements lists nine reasons to revoke a subordinate CA. The e-Tugra CPS lists only 8. e-Tugra should compare its list with the list in the BRs to ensure that its revocation practices remain compliant.	OK
4.9.12 "CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." (MRSP § 6)	Needs to be fixed - There is a typo in the URL - https://helpdesk.e-tugra.com.tr/. Also, CPS section 4.9.12 does not make it clear how to establish key compromise (It currently says, "Reports to etugra for Key Comprise include: The private key itself. A valid email address so that confirmation of your problem report and associated certificate revocations will be sent."). This list of methods is incomplete because e-Tugra has a helpdesk portal. The actual helpdesk website does not have any "top level" links to SSL certificate revocation. However, it is good that CPS section 1.5.2 has a better URL - https://helpdesk.e-tugra.com.tr/submit_ticket and the form there allows a pull-down for "Sertifika İptali / Certificate Revocation". So the URL in section 4.9.12 needs to be fixed with the URL in section 1.5.2, and the proof-of-compromise methods need to be explained better.	OK
5.7.1. Incident and Compromise Handling Procedures Indicate how your CA meets the requirements of this section, including notifying Mozilla in the event of CA key compromise. MRSP § 7 states, “Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”	Need to fix - procedures in CPS section 5.7.3 need to include notification of Application Software Suppliers in the event of a key compromise or disaster that affects the ongoing security of the CA's private key.	OK
7.1. Certificate profile CAs SHALL generate non-sequential Certificate serial numbers greater than 0 containing at least 64 bits of output from a CSPRNG. (MRSP § 5.2) Indicate how your CA meets the requirements of this section.	Needs to be fixed - The discussion of certificate serial numbers in CPS section 7.1.4 gives reference to CPS section 3.1.5, but this is not the same as the certificate serial number. For example, the serial number in a DV certificate would not be specified in section 3.1.5. Section 7.1.2 (or 7.1) should say that the certificate serial number is a non-sequential number greater than 0 containing at least 64 bits of output from a CSPRNG.	Fixed
7.1.2.2.g Subordinate CA Certificate - Separate, EKU-constrained issuing CAs (MRSP § 5.3) Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. Also, it is important to distinguish CAs using the appropriate serverAuth or emailProtection EKU. (See Required or Recommended Practices)	Should fix - e-Tugra should consider updating its explanation in CPS section 7.1.2.2 to address how it uses EKUs in subordinate CA certificates. It is insufficient to only refer to BR 7.1.2.2 and RFC 5280.	Fixed
7.1.2.3.f For TLS server certificates, either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present. id-kp-emailProtection MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present. (MRSP § 5.2)	Should fix - CPS section 7.1.2.3 says for Key Usage "Signing, key encipherment, data encipherment fields are set". However, key usage bits vary depending on which type of algorithms are used.	OK. e-tuğra has added "KeyCertSign & cRLSign values are not set", but this is not what I was trying to explain. Key usage also depends on whether it is an RSA or ECC certificate.
7.1.3.2 Signature AlgorithmIdentifier SHA-1 is prohibited (except in a very narrow exception case). (BR § 7.1.3.2.1) (MRSP § 5.1.3) (Also a Mozilla Forbidden Practice)	Should fix - CPS section 7.1.3 says, "Root certificates which are for generating subscriber certificates still have SHA-1 or SHA-256 algorithm." e-Tugra should specify the exact SHA1 root certificate that it is referring to and indicate when it intends to retire that root.	Fixed
7.1.4.2 Subject Information - Subscriber Certificates CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in BR §§ 3.2.2.4 and 3.2.2.5. Subject attributes MUST NOT contain only metadata such as ‘.’, ‘‐’, and ’ ’ (i.e. space) to indicate that it is blank, etc.	Need to fix - CPS section 7.1.4 says "The following values are used on the fields of Standard(DV) SSL" - then it has values that are not allowed in DV certificates. Generally, the only values allowed are the SAN (verified FQDN) and the country code. E-Tugra also needs to carefully review the descriptions under "values are used on the fields of Premium(OV) SSL" and make sure that they are accurate. For instance, there is only the certificate serial number allowed, and the CN MUST be one of the SANs that has been verified in accordance with BR 3.2.2.4.	OK
7.1.4.2.1 Subject Alternative Name Extension This extension MUST contain at least one entry. Each entry MUST be either a dNSName (FQDN) or an iPAddress of a server. CAs SHALL NOT issue certificates with a SAN or commonName containing a Reserved IP Address or Internal Name. (Also a Mozilla Forbidden Practice) Entries in the dNSName MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").	<- See this language -> The SAN must meet CABF/BR formatting requirements.	OK
7.1.6. Certificate Policy Object Identifier	Need to fix - CPS sections 1.2 and 7.1.2.3 need to be consistent.	OK
7.1.6.4 Subscriber Certificates Certificates MUST contain "one or more policy identifier(s) that are specified beneath the CA/Browser Forum’s reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)."	Need to fix - the policy OIDs in CPS section 7.1.2.3 need to be updated to include all applicable CA/Browser Forum OIDs.	OK
7.2 and 7.3 - All OCSP responses and CRL entries for Subordinate CA Certificates MUST include a meaningful reason code.	Need to fix - CPS needs to state that OCSP responses and CRL entries for sub CA certificates will contain a reason code.	OK
7.2.2 CRL and CRL entry extensions The issuer name for the CRL should match the issuer name in the CA certificate byte-for-byte. See Potentially Problematic Practices.	Need to fix - The CPS needs to acknowledge that issuer names on CRLs must match the name in the issuing CA's certificate byte-for-byte.	Not fixed, but OK
9.5 Intellectual Property Rights - E.g. “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” (MRSP § 3.3.3)	Should fix - The footer on the CPS states, "All rights are reserved" which is inconsistent with the grant of a Creative Commons license. See MRSP section 3.3.3. On the second page of the CPS (no page number) it states, "permission is granted to reproduce and distribute this Certification Practice Statement of e-tuğra on a nonexclusive, royalty-free basis, provided that ...." Therefore, instead of saying "All rights are reserved" the footer should say something like "Copyrighted in accordance with page ii" or whatever. Alternatively, e-Tugra could refer to the Creative Commons Attribution License 4.0 (which has some of the same language as in the CPS.	OK
9.16.3. Severability In the event of a conflicting law, the CA shall include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements and must immediately notify the CA/Browser Forum.	Need to fix - Section 1 of the CPS says, "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents." This is not the same as specifying what is done when a national law prevents e-Tugra from complying with the CA/Browser Forum's requirements.	Has this been addressed?
For CAs seeking enablement of Extended Validation
EVG 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.	Need to fix - See comment above regarding a conflict with local laws.	Same question - has this been addressed?
EVG 8.3 - the CA shall have a statement that it conforms to the current version of the EV guidelines and that in the event of any inconsistency, the EV guidelines take precedence.	Need to fix - The CPS must say that the EV Guidelines take precedence, not "If there is a conflict between one of these documents and this CPS we consult to the Regulation, Guidelines or ETSI documents."	OK
EVG 9.2.4 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency.	Needs clarfication - CPS section 3.2.2 says, "If the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province or locality level, then this field is mandatory. Otherwise this field is not included." However, it does not clarify that an irrelevant state, province or locality is omitted. EVG section 9.2.4 says, "These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency."	Fixed
EVG 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.	Need to fix- I could not locate where e-Tugra publishes its QIIS/QGIS sources, and I didn't see it here - https://e-tugra.com.tr/en/certificate-policy-and-practice-statement/.	Still need to fix
EVG 9.2.5 and 11.2.1 - subject registration number: if the jurisdiction of incorporation or registration does not provide a registration number, then the date of incorporation or registration is entered in this field.	Should fix - Section 3.1.5 didn’t indicate what e-Tugra does if there is no company registration number.	OK
EVG 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.	Need to fix - While CPS section 7.1.4 says that the address in the certificate is the "street address and number of the subject (optional)", verification of the physical location of the organization is required for EV even if it is not included in the EV certificate. Section 11.1.1 of the EV Guidelines requires verification of the Applicant’s physical existence (business presence at a physical address). This must be done in accordance with section 11.4 of the EV Guidelines. The e-Tugra CPS should explain how it establishes the street address and meets subsection 2.A. of EVG 11.4.1. Section 3.2.2 is not detailed enough. It says, "The name or the title, legal existence and physical existence of the legal entity which will take place in the certificate are verified according to the official documents of the country of residence of the applicant. " It also says "The address of the central office of the legal entity of the certificate applicant is verified according to the legal documents of the country of residence." But the address used to make a legal existence filing might be different than the street address where actual business takes place.	OK
EVG 9.2.9 - the CA shall not include any subject attributes except as specified in EVG § 9.2.	Need to fix - either section 3.1.5, 7.1.2.3, or 7.1.4 should say that for EV certificates no other subject attributes appear except those specified in section 9.2 of the EV Guidelines.	Sentence is too ambiguous and needs to be fixed. It should say something like, "No other attributes <u>not</u> mentioned in EVG 9.2 are allowed."
EVG 11.1.3 - CAs must publicly disclose Agency Information about the Incorporating Agency or Registration Agency.	Need to fix- I could not locate where e-Tugra publishes its QIIS/QGIS sources, and I didn't see it here - https://e-tugra.com.tr/en/certificate-policy-and-practice-statement/.	I think that EVG 11.1.3 requires a separately published list. Does e-tuğra mean to say that it ONLY relies on these 4 sources? https://mersis.gtb.gov.tr https://gib.gov.tr/ https://www.kaysis.gov.tr https://www.ticaretsicil.gov.tr/
EVG 11.2.2(4) - principal individuals must be validated in a face-to-face setting.	Need to fix - CPS section 3.2.3 should say that principal individuals of EV type "Business Entity" are validated face-to-face.	Fixed
EVG 11.5.1 - the CA must establish of verified method of communication with the applicant.	Need to fix - The CPS must explain how e-Tugra establishes a trusted communication channel with the true applicant/certificate subject. For instance, any fraudster could say that they are the authorized requester and provide the fraudster's own phone number for verification of the certificate request.	Fixed
EVG 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 enumerated ways: “(1) existence for at least three years, ... (2) listed in either a current QIIS or QTIS; (3) Demand Deposit Account ... by receiving authenticated documentation ... directly from a Regulated Financial Institution; or (4) ... a Verified Professional Letter ....”	Need to fix - e-Tugra must explain how it meets the requirements of EVG section 11.6.1 (operational existence).	I don't think this has been addressed.
EVG 11.9 - the CA must verify the signature on the subscriber agreement and certificate request	Need to fix - e-Tugra must explain how it verifies the signatures and the authenticity of the certificate request. See comments made under EVG 11.5.1.	OK
EVG 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.	Need to fix - e-Tugra needs to explain its processes to check the accuracy and reliability of QIISes.	OK
EVG 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.	Need to fix - e-Tugra needs to state that it checks to see whether anyone (applicant, approver, signer) is on a denied persons list as a money launderer, terrorist financier, etc.	Fixed
EVG 11.13, 14.1.3 and 16 - the CA must perform final cross-correlation and other due diligence based on the entire corpus of information and have multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance	Need to fix - e-Tugra needs to state that it conducts final cross-correlation and other due diligence based on the entire corpus of information and has multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance	I don't think this has been addressed.
EVG 11.14.3 - validation data cannot be reused after 397 days	Need to clarify how application information is reused. Section 3.3.1 of the CPS states, "For certificates of Standard(DV) SSLStandard(DV) SSL, Premium(OV) SSL, EV SSL and “CSC” and “EV SSL” there is no possibility to re-key or to renew." However, section 4.2.1 of the CPS states, "Re-use of validation information is limited to 398 days for Premium(OV) SSL, EV SSL CSC and EV CSC."	Fixed
EVG 14.1.2 – an internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.	Need to fix - CPS section 5.3.3 should specifically state that Registration Officers receive an "internal examination related to the EV Certificate validation criteria outlined in the EV Guidelines."	OK
EVG 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.	Need to fix - CPS section 5.3.7 should say that e-Tugra ensures that all third party EV contractors satisfy all training and skills requirements of section 14 of the EV Guidelines.	OK

Comment 20

[Davut Tokgöz]

Attachment: e-Tugra_CPS_v.5.1_Review_ETugraComments.xlsx

Comment 21

[Davut Tokgöz]

Dear Ben,
Thank you for re-analysis of our policy documents. We have updated our policy documents with your detailed comments. We have published on our repository. The comments about our fixes are on the excel sheet.
The updated documents E-Tuğra Repository: https://e-tugra.com.tr/en/certificate-policy-and-practice-statement
CPS is on https://e-tugra.com.tr/wp-content/uploads/2022/03/E-Tugra_CPS_v6_1.pdf
CP is on https://e-tugra.com.tr/wp-content/uploads/2022/03/E-Tugra_CP_v6_1.pdf
Regards

Comment 22

[Ben Wilson]

Here are my comments on the CP and CPS:

1. In section 7.1.2.3, for ECC certificates, the keyUsage is supposed to be "keyAgreement". For RSA it is supposed to be "keyEncipherment"
   See RFC 5280 - https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
2. In section 3.2.2, for the list of QIIS/QTIS/QGIS, it only says that it "is published on E-Tugra repository." But when I go to the E-Tugra repository, I still cannot find it. It would be better to put the URL for the landing page in the CPS and otherwise make it easier to find.
3. In section 9.16.3, it should say "If any required practice herein is found to be illegal in a jurisdiction, then e-Tugra will modify the conflicting requirement to the minimum extent necessary to make the requirement legal and will notify the CA/Browser Forum of such change in accordance with section 9.16.3 of the Baseline Requirements and section 8.1 of the EV Guidelines."

Thanks,

Ben

Comment 23

[Davut Tokgöz]

Dear Ben
Thanks for your feedback. We reviewed your feedback and based on that we did updates in the CPS to reflect the desired changes.
We have published CPS v6.2 on website also. We have covered the following things this time:
• 3.2.2 > “Agency Information” document link (https://e-tugra.com.tr/wp-content/uploads/2022/03/E-Tugra_Agency_Information.pdf) was inserted.
• 7.1.2.3 > Key Usage are changed for both RSA and ECC certificates.
• 9.16.3 > text revised.
E-Tuğra Repository: https://e-tugra.com.tr/en/certificate-policy-and-practice-statement
CPS is on https://e-tugra.com.tr/wp-content/uploads/2022/03/E-Tugra_CPS_v6_2.pdf
CP is on https://e-tugra.com.tr/wp-content/uploads/2022/03/E-Tugra_CP_v6_2.pdf
Regards

Comment 24

[Ben Wilson]

Public discussion began today, with the 3-week public discussion period scheduled to end on 20-April-2022.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ylNHGT1arUE/m/GKcyixI8FAAJ

Comment 25

[Ben Wilson]

Public discussion has concluded, https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ylNHGT1arUE/m/ievUcp4uCwAJ, and I am recommending that this inclusion request be approved.

Comment 26

[Kathleen Wilson]

The reason that I have not approved this request yet, is because I am seeing errors when running the EV Checker for the test websites.

https://tls-observatory.services.mozilla.com/static/ev-checker.html
TLS Server: https://evvalidrsa.e-tugra.com.tr
TLS Server: https://evvalidecc.e-tugra.com.tr
EV Policy OID: 2.23.140.1.1

Comment 27

[Dimitris Zacharopoulos]

The issuing CA contains policy OID 1.3.6.1.5.5.7.2.1. According to RFC5280 there is no policy tree path to assert the 2.23.140.1.1 OID. We hope https://bugzilla.mozilla.org/show_bug.cgi?id=1699796 can assist.

Comment 28

[Davut Tokgöz]

Attachment: EvCheck for RSA v3

Comment 29

[Davut Tokgöz]

Attachment: EvCheck for ECC v3

Comment 30

[Davut Tokgöz]

Hi Kathleen
The problem was fixed and EV tests were completed as seen attachments. Please can you recheck them?
Hi Dimitris
Thank you for your assist and cooperation. The problem was fixing First OID on the TLS certificates and the using EV OID 2.23.140.1.1 in Intermediate certificate, as on https://wiki.mozilla.org/CA/EV_Processing_for_CAs#First_OID . All was fixed.
Regards

Comment 31

[Dimitris Zacharopoulos]

Thank you Davut, it appears that you created also a new Issuing CA (issued 2022-05-18), fixing the missing policy OID from the certificatePolicies extension. That's good news!

Comment 32

[Kathleen Wilson]

As per Comment #25, and on behalf of Mozilla I approve this request from E-Tugra to include the following root certificates:

** E-Tugra Global Root CA RSA v3 (Websites); enable EV
** E-Tugra Global Root CA ECC v3 (Websites); enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 33

[Kathleen Wilson]

I have filed bug #1770267 against NSS and bug #1770269 against PSM for the actual changes.