Closed Bug 443653 Opened 17 years ago Closed 14 years ago

Add Root (EBG Informatic Technologies and Services Corp. (E-Tugra))

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: katsan11, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: In Firefox 3.6 )

Attachments

(12 files, 1 obsolete file)

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; {1A69D488-81A8-453A-B069-E104E7A7EF76}; .NET CLR 1.1.4322; FDM; .NET CLR 2.0.50727) Build Identifier: The link to Certificate Data : http://www.e-tugra.com.tr/_eTugra/web/WPX/EBG_KOKSM.crt Our Root issues certificates for all the following purposes. SSL-enabled servers, digitally-signed and/or encrypted email, or digitally-signed executable code objects; Our Root does not issues extended Validation certificates. Links to CP and CPS : http://www.e-tugra.com.tr/_eTugra/web/WPX/EBGNESI.pdf http://www.e-tugra.com.tr/_eTugra/web/WPX/EBGNESUE.pdf We are a legaly authorized CPS operating in Turkey and accredited by Turkish Telecommunications authority. We verify certificate signing requests inline with the electronic signature law and regulations of Turkey. Our certification can be found at : http://www.tk.gov.tr/eimza/doc/aciklama/etura.jpg Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Inclusion of our root Certificate in the Mozilla trusted store. Thank you for your consideration.
Is there a reason you marked this bug as "security sensitive"? That keeps it from being seen by the public (and from the people who normally handle these requests).
None of the others have been hidden, opening this up.
Group: security
Koray, Please see the following web pages for the complete set of information that must be provided in this bug in order for your request to be considered: http://wiki.mozilla.org/CA:Information_checklist http://wiki.mozilla.org/CA:Root_Certificate_Requests Other pages with related information may be found at http://wiki.mozilla.org/CA:Overview
Hello All, No specific reason. I just dont know the procedure. I have no problems with opening it up now. I will be gathering the required information and get back to the discussion. Many Thanks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Request for inclusion of our Root CA certificate to Firefox Trusted Root Store (EBG Informatic Technologies and Services Corp. (E-Tugra)) → Add Root (EBG Informatic Technologies and Services Corp. (E-Tugra))
In the duplicate bug, Frank wrote: The E-Tuğra web site is <http://www.etugra.com/>; the URL <http://www.tk.gov.tr/eimza/eshs.htm> has links to Turkish government information relating to the CA.
Hello All, Sorry it took us some time to get back to the discussion. We would like to move forward now with the process. Here is the complete list of answers for certificate requests : CA Details ---------- CA Name: EBG Bilişim Teknolojileri ve Hizmetleri A.Ş. (E-TUGRA) Website URL: http://etugra.com.tr CA Summary: [ A one Paragraph Summary of your CA, ] EBG Bilişim Teknolojileri ve Hizmetleri A.Ş. (EBG Informatics Technologies and Services Corp.) (E-TUGRA) is a privately held CA operating since 09/2006 in Ankara/Turkey. E-TUGRA has been certified as one of the 4 authorized CA s that issue qualified certificates as well as SSL and other types of certificates to public in Turkey. (Pls. see http://www.tk.gov.tr/eimza/eshs.htm) E-TUGRA has customers from all over Turkey and provide its services to all geographic areas within Turkey. E-TUGRA has a root CA on top of its hierarchy and two sub CA s below th e Root CA namely ; Qualified Sub CA and SSL Sub CA. Audit Type (WebTrust, ETSI etc.): ETSI 101456 Auditor: Turkish Telecommunications Agency Auditor Website URL: http://tk.gov.tr Audit Document URL(s): http://www.tk.gov.tr/eimza/doc/aciklama/etura.jpg URL of certificate hierarchy diagram (if available): NA Certificate Details ------------------- (To be completed once for each root certificate; note that we only include root certificates in the store, not intermediates.) Certificate Name: EBG Elektronik Sertifika Hizmet Sağlayıcısı Summary Paragraph: E-TUGRA has a single root and 2 sub CA s certified by the root. We plan to have at most 2 Levels of PKI hierarchy and issue end entity certificates from the second level CAs. Root certificate download URL (on CA website): http://www.etugra.com.tr/Portals/3/bilgideposu/EBG_KOKSM.zip [alternatively, paste a copy of the certificate in "PEM" format ] Certificate SHA1 Fingerprint (in hexadecimal): 8c 96 ba eb dd 2b 07 07 48 ee 30 32 66 a0 f3 98 6e 7c ae 58 Key size (for RSA, modulus length) in bits: 4096 bits Valid From (YYYY-MM-DD): 17.08.2006 Vlid To (YYYY-MM-DD): 14.08.2016 CRL HTTP URL (if any): http://crl.e-tugra.com.tr/e-tugra_ksm.crl CRL issuing frequency for subordinate CA certificates: 1 day CRL issuing frequency for subordinate EE certificates: [ days ] OCSP responder URL (if any): http://ocsp.e-tugra.com/status/ocsp Class: [domain-validated, identity/organizationally-validated or EV ] Both Domain Validated and Identity/Organizationally validated. Certificate Policy URL: http://www.etugra.com.tr/Portals/3/Templates/NQC_CpCps.pdf CPS URL: http://www.etugra.com.tr/Portals/3/Templates/NQC_CpCps.pdf Requested Trust Indicators: [ email and/or SSL and/or code signing ] Timestamping, Server authentication, Client authentication, Secure Email, OCSP URL of a sample website using a certificate chained to this root (if applying for SSL): https://webmail.takasbank.com.tr/
Hello There Shall i open a new bug for this issue if this is not taken care of ? Thank you.
Accepting this bug, to start the info-gathering and verification phase.
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
Attached is the initial information gathering document which summarizes the information that has been gathered and verified. Would you please review it to make sure you agree with the information captured therein? As per the items highlighted in yellow in the attached document, would you please provide a little bit more detail about the subordinate CAs and what types of certs they are used to issue? Are all of the subordinate CAs operated internally? I have reviewed the CPS to look for potentially problematic practices as per http://wiki.mozilla.org/CA:Problematic_Practices. I did not find any information in the CPS that leads me to believe any of these practices apply. Would you please comment as to whether any of these problematic practices are relevant? If relevant, please provide further info. Thanks, Kathleen
Thank you very much for this quick review. I have included our explanations in the Initial information gathering document. None of the potentially problematic practices apply to our certification practices as we tend to keep our PKI fairly simple but effective. Many Thanks Koray
Attachment #338077 - Attachment description: Includes explanations regarding the Information gathering document → Explanations - Information gathering document
The information gathering phase of this request is complete. Assigning bug to Frank so he can proceed with the next (public discussion) phase. I will update the pending list to include this root. There will be a slight delay before the changes are visible. Thanks, Kathleen
Assignee: kathleen95014 → hecker
Whiteboard: Information confirmed complete
Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.
Assignee: hecker → kathleen95014
I am re-reviewing the information in this request in preparation for the upcoming public discussion, as described in https://wiki.mozilla.org/CA:How_to_apply#Public_discussion https://wiki.mozilla.org/CA:Schedule 1) Audit http://www.tk.gov.tr/eimza/doc/aciklama/etura.jpg This audit statement is from 2007. Have you had a more recent audit against the ETS 101 456 criteria? If so, would you please provide an auditor’s statement regarding when the last audit was completed and the criteria that was used in the audit? 2) Potentially Problematic Practices Would you please review the updated list of Potentially Problematic Practices and provide further information for the relevant items? http://wiki.mozilla.org/CA:Problematic_Practices 3) OCSP The test website https://webmail.takasbank.com.tr/ loads into Firefox without error when I don’t have OCSP enforced. When I enforce OCSP in Firefox, the website results in the following error: An error occurred during a connection to webmail.takasbank.com.tr. The OCSP server returned unexpected/invalid HTTP data. (Error code: sec_error_ocsp_bad_http_response) Thanks, Kathleen
Attached file The desired root cert
The URL given for the root CA cert in comment 0 returns a 404 error page, so I'm attaching the desired root cert here.
(In reply to comment #16) > 3) OCSP > The test website https://webmail.takasbank.com.tr/ loads into Firefox > without error when I don’t have OCSP enforced. When I enforce OCSP in > Firefox, the website results in the following error: > > An error occurred during a connection to webmail.takasbank.com.tr. > The OCSP server returned unexpected/invalid HTTP data. > (Error code: sec_error_ocsp_bad_http_response) That error message appears because the OCSP responder responds to the OCSP request with an error 500 and an html error page full of Java stacks. A copy of that http error page is attached here for your inspection.
According to the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion this request may enter public discussion in about two weeks. The process is described at https://wiki.mozilla.org/CA:How_to_apply#Public_discussion However, I will not be able to start the public discussion for this request until someone from E-Tugra has provided the information that I requested in Comment #16.
We are sorry to answer you lately. We don’t publish SSL certificate to OCSP server. To publish and install the SSL certificate support to OCSP is required time for us. After installing SSL certificate support to the test server for OCSP. We tested it. Now we put it in production environment for two days. Could you please to test again. Regards.
Now when I enforce OCSP in Firefox and try to go to https://webmail.takasbank.com.tr/ I get the error: sec_error_ocsp_invalid_signing_cert Is the OCSP response signed by a cert under a different root? You should be able to test it in Firefox by going to Tools -> Options -> Validation and click the box for "When an OCSP server connection fails, treat the certificate as invalid." More urgently... Do you have an update in regards to my questions about audit and potentially problematic practices?
We fixed the OCSP Server Sign Certificate for “sec_error_ocsp_invalid signing_cert”. Now the OCSP response is correct. The last audit document link is http://www.e-tugra.com.tr/Portals/3/E-Tugra_audit_09.pdf
We fixed the OCSP Server Sign Certificate for “sec_error_ocsp_invalid signing_cert”. Now the OCSP response is correct. The last audit document link is http://www.e-tugra.com.tr/Portals/3/E-Tugra_audit_09.pdf
I can now load the test website when OCSP is enforced. Thanks for fixing. I have sent email to the auditor (ICTA) to confirm the authenticity of the audit statement, as is Mozilla process when the statement is provided by the CA.
I have received the following response from the auditor: > Subject: RE: Requesting Confirmation of Authenticity of Audit Statement for E-Tugra > > As one of the audit team members I would like to confirm > that we (ICTA) have issued the audit statement at the > mentioned URL. > > In Turkey, electronic certificate service provider such as > e-Tugra shall be inspected by the ICTA when it is > necessary and at least biannual at the ICTA's own > initiative.
Updating the Information Gathering Document in preparation for the public discussion.
Attachment #338206 - Attachment is obsolete: true
Hello Kathleen We would like to thank you for your hard work on accepting our root certificates for public discussion phase. Even though we would like to promote Firefox to our customer base, unfortunately because of long approval process we could not support Firefox up to now. We hope that after this we could be included in short time to Firefox and start to work with Firefox with our customers. Best regards
I am now opening the first public discussion period for this request from E-TUGRA to add the EBG Elektronik Sertifika Hizmet Sağlayıcısı root certificate to NSS and enable all three trust bits. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “E-TUGRA Root Inclusion Request” Please actively review, respond, and contribute to the discussion.
Whiteboard: Information confirmed complete → In public discussion
The first discussion for this request from E-TUGRA to add the EBG Elektronik Sertifika Hizmet Sağlayıcısı root certificate to NSS and enable all three trust bits, is now closed. The action items resulting from this discussion are as follows: 1) E-TUGRA is requested to update the NQC CP/CPS to clearly explain the process for verifying the identity/existence of the organization for corporate applications, both within Turkey and outside Turkey. The verification procedures must include cross-verifying the information provided by the subscriber with a third party source. If the information is notarized, the procedure should include ensuring that the notary is authorized accordingly. 2) E-TUGRA is requested to update the NQC CP/CPS to clarify the procedure for verifying the ownership/control of the domain name for SSL cert applications, especially in regards to applicants for non-Turkish (foreign) domains. The procedure for verifying domains needs to explain the controls to ensure that the data retrieved both from the applicant and from the third-party whois sites is authentic. 3) After E-TUGRA updates the bug to post the link to the updated NQC CP/CPS, Kathleen will enter the request into the second round of public discussion.
The public comment period for this request is now over. This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for E- Tugra’s request to add the EBG Elektronik Sertifika Hizmet Sağlayıcısı root certificate to the Mozilla root store, and enable all three trust bits. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by E-Tugra, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. E-Tugra appears to provide a service relevant to Mozilla users: It is a privately held CA with customers from all geographic areas within Turkey. Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the CP/CPS for both the Qualified and the Non Qualified certificates, which are provided in English. Non Qualified (NQC) CP/CPS: http://www.e-tugra.com.tr/Portals/3/Templates/NQC_CpCps_v1.1.pdf Qualified (QC) CP/CPS: http://www.e-tugra.com.tr/Portals/3/Templates/QC_CpCps.pdf Section 7 [Validation]. E-Tugra appears to meet the minimum requirements for subscriber verification, as follows: * Email: E-Tugra verifies that the applicant owns/controls the email address to be included in the certificate by means of an e-mail authentication and a secret question challenge. This is done by sending an e-mail to the proclaimed e-mail address which includes a challenge question which is already obtained from the NQC application form. In case a reply from the applicants proclaimed e-mail address is received and the answer to the challenge question is correct, then the verification process is successfully completed. * SSL: E-Tugra verifies that the applicant owns/controls the domain name by comparing the information in the application with query results from https://www.nic.tr/ for Turkish domain names, and WHOIS for non-Turkish domain names. E-Tugra also sends metatag to be placed on the server and verifies it’s presence in order to verify that if person has access to the server with domain for requested certificate. * Code: E-Tugra verifies the identity and the authorization of the entity submitting the certificate signing request. Section 8-10 [Audit]. Section 8-10 [Audit]. * E-Tugra is audited by the Turkish Information and Communications Technologies Authority (ICTA) every other year. The ICTA has provided a statement that they last audited E- TUGRA in May, 2008. The statement says that the audit covers the ETSI TS 101 456 criteria. The ICTA website lists E- TUGRA as one of the qualified/audited CAs, and I have exchanged email with a representative of ICTA to confirm the authenticity of the audit statement. Section 13 [Certificate Hierarchy]. * The EBG Elektronik Sertifika Hizmet Sağlayıcısı root certificate has issued two internally-operated subordinate CAs. The Qualified Certificate (QC) subordinate CA issues certificates for Digital Signing and Non-Repudiation (document and email signing). The Non Qualified Certificate (NQC) subordinate CA issues certificates for SSL, email encryption, and code signing. Other: * Both CRL and OCSP are provided. ** NextUpdate for the CRL for website certs is 24 hours. Potentially problematic practices: None noted. Based on this assessment I recommend that Mozilla approve this request to add the EBG Elektronik Sertifika Hizmet Sağlayıcısı root certificate to the Mozilla root store, and enable all three trust bits. Note: E-Tugra is requested to add their updated audit to this bug when it becomes available, and have the auditor note (or provide a separate statement) that the changes in the NQC CP/CPS have also been reviewed and the corresponding procedures audited. Since the changes to the NQC CP/CPS centered on clarification of procedures especially in regards to non-Turkish applicants, I recommend that the approval and the inclusion phase proceed, and that the updated audit be tracked independently.
Hi Kathleen, Thanks again for your all input an effort. We agree we will provide you whith additional note about update auditing on changes in our CPS when it is available. Is there anything that we should do further to fasten your approval? Best regards.
To Kathleen: Thank you for your work on this request. To the representatives of E-Tugra: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. I have reviewed the summary and recommendation in comment #31, and on behalf of the Mozilla project I approve this request from E-Tugra to include the following root certificate in Mozilla, with trust bits set as indicated: * EBG Elektronik Sertifika Hizmet Sağlayıcısı (web sites, email, code signing) (I acknowledge the note in comment #31 about updating the audit report, and agree that it can be handled separately and is not an impediment to inclusion.) Kathleen, could you please file the necessary bugs against NSS and PSM to effect the approved changes? When those bugs are completed please change the status of this bug to RESOLVED FIXED. Thanks in advance!
Whiteboard: In public discussion → Approved
(In reply to comment #32) > Is there anything that we should do further to fasten your approval? No, you are now officially approved for inclusion in Firefox and other Mozilla products. Congratulations! However, you still need to work with our developers to make sure that your root certificate will be correctly added, and that no technical problems occur. Please read the bug report(s) that Kathleen files for inclusion of your root, answer whatever further technical questions relating to your root, and perform any testing asked of you.
> [...] you still need to work with our developers to make sure that your root > certificate will be correctly added, and that no technical problems occur. Is there any remaining doubt about "technical problems" with this cert? If so, they should be resolved before a request is made to add the cert to NSS.
(In reply to comment #35) > Is there any remaining doubt about "technical problems" with this cert? No. I was simply referring to the normal process of double-checking to make sure that the root gets included in NSS properly, e.g., using test versions of NSS incorporating the new root with a copy of Firefox to confirm that Firefox can properly recognize certs issued under the root's hierarchy.
Depends on: 509440
I have filed bug 509440 against NSS for the actual changes.
ACTION: E-Tugra is requested to add their updated audit to this bug when it becomes available, and have the auditor note (or provide a separate statement) that the changes in the NQC CP/CPS have also been reviewed and the corresponding procedures audited. Since the changes to the NQC CP/CPS centered on clarification of procedures especially in regards to non-Turkish applicants, I recommend that the approval and the inclusion phase proceed, and that the updated audit be tracked independently. Calling this action item out separately, so this bug doesn't get closed until the action item is also completed.
Whiteboard: Approved → Approved - In NSS - Awaiting updated Audit (!?)
Whiteboard: Approved - In NSS - Awaiting updated Audit (!?) → Approved - In NSS - Awaiting updated Audit
I have confirmed that this root is now a Builtin Object Token in Firefox 3.6. However, this bug will remain open until E-Tugra has completed their action item as per Comment #38. Semih, Please update this bug when E-Tugra has completed the action item.
Whiteboard: Approved - In NSS - Awaiting updated Audit → In Firefox 3.6 - E-Tugra has an open action item
Semih, Please provide a link to the updated audit statement.
Semih, Please provide an update to the action item. ACTION: E-Tugra is requested to add their updated audit to this bug when it becomes available, and have the auditor note (or provide a separate statement) that the changes in the NQC CP/CPS have also been reviewed and the corresponding procedures audited.
Hi Kathleen, We shall auditing in May or August. We will send you a auditor note after auditing. CP/CPS to update and will inform you about the situation. Best Regards,
Attached file Audit Statement 2010
From 2010 Audit Statement: 4. We also hereby declare the fact that EBG complies with "ETSI TS 101 456"... 5. Last Supervision to EBG was done on 21-25 June 2010 by ICTA From E-Tugra representative via email: ... we are waiting audit statement report link refresh on Turkish Information and Communicatin Technologies Authority's site. ...we are still valid/approved company by goverment. http://www.tk.gov.tr/eimza/doc/aciklama/etura9.jpg
The updated audit statement has been posted on the website of Turkey's Information and Communication Technologies Authority. http://www.tk.gov.tr/eimza/eshs.htm
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: In Firefox 3.6 - E-Tugra has an open action item → In Firefox 3.6
Attached file 2012 Audit Statement
EBG (E-Tugra) is listed as a qualified electronic certificate service provider on the BTK website: http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/eshs.php
Hi, The existing root certificate of E-Tugra that had already been included to the trusted CA list on the Mozilla store, will be expired on August, 2016 which means expires on in 3 years. And according the laws of of Turkey which revised about 5 mounts ago, we have to issue new certificates with at least sha256 algorithm and with 2048 bits after July, 2013. For these reasons, we have already produced a new root certificate. The certificate was produced under the observation of Qualified Auditor witness according to requirements of “Key Generation Ceremony” of “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” and “Guidelines for Issuance and Management of Extended Validation Certificates” published at http://www.cabforum.org by “CA/Browser Forum”. The observation letter of the E-Tugra key ceremony by of Qualified Auditor witness is attached. We want to add this new root to Mozilla store as well. The new root certificate is attached. Certificate Name is “E-Tugra Certification Authority” Sha1 Fingerprint is : 51c6e70849066ef392d45ca00d6da3628fc35239 Sha2 fingerprint is : b0bfd52bb0d7d9bd92bf5d4dc13da255c02c542f378365ea893911f55e55f23c We update and arrange our CP and CPS by including new root and EV SSL requirements with “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” and “Guidelines for Issuance and Management of Extended Validation Certificates” published at http://www.cabforum.org by “CA/Browser Forum”. Their English and Turkish versions of them are also attached and they are published on www.e-tugra.com.tr/cps. E-Tugra was also completed auditing process by the BIS for the EV SSL issuance according to ETSI 102 042. New CP and CPS covers EV SSL certificates and its policies with respect to guidelines on cabforum. So, we expected • The new root certificate should be included to Mozilla Root CA Store as existing root. • Enable new E-Tugra root certificate for EV.
Attached file CPS version 3.0
Attached file CP version 3.0
Attached file E-Tugra Second Root
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: