433845 - Add TÜRKTRUST Root CA

Status: RESOLVED FIXED

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

Description

[Mert Özarar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

We have already produced and  declared a new root hierarchy and we obviously want to add this third hierarchy to Mozilla store as well. Notice that with the update 2.0.13, the previous two root certificates of TÜRKTRUST had already been included to the trusted CA list. Related bug report can be reached with bug number 380635.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.


Expected Results:  
The new root hierarchy should be included to Mozilla Root CA Store as included previously.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I confirm this is an enhancement request.

Comment 2

[Mert Özarar]

Attachment: TÜRKTRUST CA Root Certificate 3

Comment 3

[Mert Özarar]

Attachment: TURKTRUST Root Hierarchy - III

Comment 4

[Mert Özarar]

Attachment: CPS associated with the new root (MSWord document)

Comment 5

[Mert Özarar]

Dear Frank,

* A copy of the new root CA certificate has been attached to the report.
* The related information on what subordinate CAs exist under this
root can be accessed through the "TURKTRUST Root Hierarchy - III" image file. All of those subordinate CAs will be operated and controlled by TURKTRUST.
* The qualified electronic certificates (suitable with Turkish Electronic Signature Law) are the only type of end entity certificates that will be issued under this new root's hierarchy.
* The related CPS (English version) is also attached associated with this root.
* This new root will be incorporated in our CA audit same as the previous ones. Same measures, same audit, in short exactly same as those previous two roots.

Best regards,

Mert ÖZARAR
TURKTRUST Representative

Comment 6

[Kathleen Wilson]

Accepting this bug so I can proceed with the information gathering and verification phase.

Comment 7

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the initial information gathering document which summarizes the information that has been gathered and verified for this request. Please review the document and let me know if you would like to make further clarifications or corrections. The items highlighted in yellow in the attached document indicate the information that is still needed.  I will summarize below:

1) It looks like only the email trust bit needs to be enabled for this root. Please confirm or correct.
As you know, you can enable one or more of the trust bits:
Websites (SSL/TLS)
Email (S/MIME)
Code (Code Signing)

2) For testing purposes, please provide a sample certificate chaining up to this root.

3) Please provide a recent audit report that satisfies sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

Thanks,
Kathleen

Comment 8

[Kathleen Wilson]

There has been no activity in this bug for over a year.

Is this request obsolete?

Comment 9

[Kathleen Wilson]

Closing bug due to no recent response from CA.

Comment 10

[Kathleen Wilson]

Re-opening per request from the CA. This request is still valid, and the CA will respond soon.

Comment 11

[Mert Özarar]

Attachment: Sample Certificate Issued by Target Root Hierarchy

Comment 12

[Mert Özarar]

Attachment: The most recent Audit Report of TURKTRUST

Comment 13

[Mert Özarar]

I have reviewed the initial Information Gathering Document and the needed answers to the items highlighted in yellow are as follows:

1. All of the trust bits 
- Websites (SSL/TLS)
- Email (S/MIME)
- Code (Code Signing)
can be enabled for this root hierarchy.

2. A sample certificate chaining up to this root has been uploaded to the attachments with the file name "SampleCertificate.cer" in DER-encoded form.

3. The most recent audit report has also been uploaded to the attachments with the file name "turktrust9.gif".

Warmest regards,

Mert ÖZARAR
TURKTRUST Representative

Comment 14

[Kathleen Wilson]

Thank you for the information. I would like to request some more information.

1) Please explain the relation between this root and the other TURKTRUST roots currently included in NSS.

2) Since you want to enable the websites trust bit for this root, please provide a url to a website whose SSL cert chains up to this root. (may be a test website)

3) Please provide updated information about the sub-CAs under this root. How many sub-CAs are signed by this root, what are they, what do they sign? Are any (or will any) sub-CAs be operated by third parties? Has (or will) this root been involved in cross-signing with another root?

4) Please review the http://wiki.mozilla.org/CA:Problematic_Practices wiki page and provide further information about the items that are relevant.

Comment 15

[Mert Özarar]

Here are the answers, sorry for the late reply:

1. This root stands in a horizontal hierarchy  with others. The main aim of this root is to issue certificates for Mobile PKI (i.e. mobile signatures).

2. https://destek.turktrust.com.tr 

3. 
 i. QEC Sub Root
 ii. SSL Sub Root
 iii. OCSP Responder Certificate
 iv. Time Stamping Certificate

4. Understood, shall revert if necessary.

What will be our next step?

Warmest regards,

Mert ÖZARAR
TURKTRUST Representative

Comment 16

[Kathleen Wilson]

Thank you for the clarification.

In regards to the test website: https://destek.turktrust.com.tr/
When I enforce OCSP in my Firefox browser and try to load this website, I get the error:
Invalid OCSP signing certificate in OCSP response.
(Error code: sec_error_ocsp_invalid_signing_cert)
Please see: https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root

> What will be our next step?
After the information gathering and verification step is completed, the next step is the queue for public discussion: 
https://wiki.mozilla.org/CA:How_to_apply#Timeline

Comment 17

[Mert Özarar]

Thanks Kate for the remark, we have solved the error. Please check it out.

Looking forward to taking a position in the queue.

(In reply to comment #16)
> Thank you for the clarification.
> 
> In regards to the test website: https://destek.turktrust.com.tr/
> When I enforce OCSP in my Firefox browser and try to load this website, I get
> the error:
> Invalid OCSP signing certificate in OCSP response.
> (Error code: sec_error_ocsp_invalid_signing_cert)
> Please see:
> https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root
> 
> > What will be our next step?
> After the information gathering and verification step is completed, the next
> step is the queue for public discussion: 
> https://wiki.mozilla.org/CA:How_to_apply#Timeline

Comment 18

[Kathleen Wilson]

I just tried a few times, and it still fails for me. Maybe I need to wait for the changes to get propagated to the servers?

Comment 19

[Kathleen Wilson]

I just tried connecting to https://destek.turktrust.com.tr/ again, and I get the error:
An error occurred during a connection to destek.turktrust.com.tr.
Invalid OCSP signing certificate in OCSP response.
(Error code: sec_error_ocsp_invalid_signing_cert)

If I turn off enforcement of OCSP in my Firefox browser the page loads.

Note that when I turn enforcement of OCSP back on, I clear the history in my browser. Then I get the error when I try to access the website again.

Comment 20

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 21

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 22

[Kathleen Wilson]

This request is also to EV-enable this root, as per bug #715136.

Comment 24

[Kathleen Wilson]

I am reviewing my notes for this request.  Please...

1) Provide a test website whose EV SSL cert chains up to this root.

2) Perform the EV testing as described here 
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
(this item will not hold up discussion, but will be needed before I can file the PSM bug)

3) Provide more recent audit statements or an estimate of when they will be available.
The ones I have are:
http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/TURKTRUST_LETTER_2011.pdf (2011.10.17)
https://bugzilla.mozilla.org/attachment.cgi?id=585759  (2011.12.20)

4) In regards to http://wiki.mozilla.org/CA:Problematic_Practices
Does TurkTrust issue certs referencing hostnames or private IP addresses or issue SSL certs for internal domains?

Comment 25

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #24)
> 3) Provide more recent audit statements or an estimate of when they will be
> available.
> The ones I have are:
> http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/
> TURKTRUST_LETTER_2011.pdf (2011.10.17)
> https://bugzilla.mozilla.org/attachment.cgi?id=585759  (2011.12.20)


Ooops! Please ignore #3.

Comment 26

[Kathleen Wilson]

The following statements in the CPS seem to contradict each other:

* CPS section 3.2.2.1, QEC, SSL or OSC: The e-mail address submitted by the authorized person who conducts the application operations on behalf of the subscriber should be verified. This verification is done with a unique user name and activation code sent to the authorized person’s e-mail address.

* CPS section 3.2.4: The e-mail addresses in QEC applications are accepted upon the declaration of the applicant and contained in the certificate without further verification.

Comment 27

[Mert Özarar]

Attachment: Corrected Version of CPS

Comment 28

[Mert Özarar]

The Turkish version of the CPS is correct yet there has been a mistake during English translation most probably (copy/paste mistake). You can find the corrected version of our latest CPS where in 3.2.2.1;
"For SSL and OSC applications, the e-mail address submitted by the authorized person
who conducts the application operations on behalf of the subscriber should be verified. This verification is done with a unique user name and activation code sent to the authorized person’s e-mail address."

* QEC has been cancelled out in the translated text.

Thanks for warning,

Regards,

Mert

Comment 29

[Mert Özarar]

The answers to the questions are as follows:

1. https://evssl.turktrust.com.tr

2. We have passed through the given URL (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version).
It says:
"We are willing to help you produce those technical representation. If you have started the formal process to request being added to the Mozilla root store, and have attached your root to a bugzilla bug, you may ask us to produce it for you."

Could you please provide us this text file? We have done the previous steps.

4. Simply, does not.

Mert

Comment 30

[Kathleen Wilson]

Is this request to turn on all three trust bits? 
1) Websites (SSL/TLS)
2) Email (S/MIME)
3) Code (Code Signing)

Please see item #7 of
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

I am not finding the text in the CP/CPS that satisfies this: 
"for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;"

Therefore, I think that this request should be to turn on the websites and code signing trust bits, but not the email trust bit.

Comment 31

[Kathleen Wilson]

(In reply to Mert Özarar from comment #29)
> 
> 1. https://evssl.turktrust.com.tr

I imported the root cert into my browser, but I get the following error when I try to browse to this website when I have OCSP set to hard fail when the OCSP server connection fails. When I un-check the box to hard fail when OCSP fails, then I am able to browse to the website.

Please see https://wiki.mozilla.org/CA:Recommended_Practices#OCSP

The signer of the OCSP response is not authorized to give status for this certificate.
(Error code: sec_error_ocsp_unauthorized_response)

Comment 32

[Kathleen Wilson]

(In reply to Mert Özarar from comment #29)
> 
> 2. We have passed through the given URL
> (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version).
> It says:
> "We are willing to help you produce those technical representation. If you
> have started the formal process to request being added to the Mozilla root
> store, and have attached your root to a bugzilla bug, you may ask us to
> produce it for you."
> 
> Could you please provide us this text file? We have done the previous steps.
> 

I have sent email to Kai asking him to create the file. Note that this just needs to be done before I create the PSM bug. The discussion and approval phase may proceed after Comment #30 and Comment #31 are resolved.

Comment 33

[Kathleen Wilson]

What may your OCSP response maximum expiration time be set to?

CA/Browser Forum's EV Guidelines Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”

Comment 34

[Mert Özarar]

(In reply to Kathleen Wilson from comment #30)
> Is this request to turn on all three trust bits? 
> 1) Websites (SSL/TLS)
> 2) Email (S/MIME)
> 3) Code (Code Signing)
> 
> Please see item #7 of
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
> 
> I am not finding the text in the CP/CPS that satisfies this: 
> "for a certificate to be used for digitally signing or encrypting email
> messages, the CA takes reasonable measures to verify that the entity
> submitting the request controls the email account associated with the email
> address referenced in the certificate or has been authorized by the email
> account holder to act on the account holder's behalf;"
> 
> Therefore, I think that this request should be to turn on the websites and
> code signing trust bits, but not the email trust bit.

Obviously, those two trust bits should be turned on.

Comment 35

[Kathleen Wilson]

(In reply to Mert Özarar from comment #34)
> > 
> > Therefore, I think that this request should be to turn on the websites and
> > code signing trust bits, but not the email trust bit.
> 
> Obviously, those two trust bits should be turned on.


OK. I will update my notes to indicate that this request is to turn on the websites and code signing trust bits, and not the email trust bit.

I am getting intermittent errors with the test website https://evssl.turktrust.com.tr/
Sometimes I'm able to browse to this site without error, and other times I get the
error:
An error occurred during a connection to evssl.turktrust.com.tr.
The signer of the OCSP response is not authorized to give status for this certificate.
(Error code: sec_error_ocsp_unauthorized_response)

Right now the behavior is that if I copy-paste the url (https://evssl.turktrust.com.tr/), I browse to it without error. Then if I do a Reload, I get the error.

Comment 36

[Mert Özarar]

It is an interesting case, what kind of responses do you get? Could you please share them with us? We've checked out our responder yet could not find a concrete misconfiguration. We need your help to fix the case.



(In reply to Kathleen Wilson from comment #35)
> (In reply to Mert Özarar from comment #34)
> > > 
> > > Therefore, I think that this request should be to turn on the websites and
> > > code signing trust bits, but not the email trust bit.
> > 
> > Obviously, those two trust bits should be turned on.
> 
> 
> OK. I will update my notes to indicate that this request is to turn on the
> websites and code signing trust bits, and not the email trust bit.
> 
> I am getting intermittent errors with the test website
> https://evssl.turktrust.com.tr/
> Sometimes I'm able to browse to this site without error, and other times I
> get the
> error:
> An error occurred during a connection to evssl.turktrust.com.tr.
> The signer of the OCSP response is not authorized to give status for this
> certificate.
> (Error code: sec_error_ocsp_unauthorized_response)
> 
> Right now the behavior is that if I copy-paste the url
> (https://evssl.turktrust.com.tr/), I browse to it without error. Then if I
> do a Reload, I get the error.

Comment 37

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #35)
> I am getting intermittent errors with the test website
> https://evssl.turktrust.com.tr/
>

I just tried again several times and got the following error:

An error occurred during a connection to evssl.turktrust.com.tr.
The signer of the OCSP response is not authorized to give status for this certificate.
(Error code: sec_error_ocsp_unauthorized_response)

I have manually imported this root:
http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi_s3.crt

Comment 38

[Kathleen Wilson]

Please use a fresh cert8.db to test:
https://wiki.mozilla.org/CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings

Then import the new root (let me know if the url I've been using is wrong), and turn on the websites trust bit.

Then browse to https://evssl.turktrust.com.tr/

Comment 39

[Kai Engert [:KaiE:]]

Attachment: test_ev_roots for F1:7F:6F:B6:31:DC:99:E3:A3:C8:7F:FE:1C:F1:81:10:88:D9:60:33

(In reply to Mert Özarar from comment #29)
> 
> 2. We have passed through the given URL
> (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version).
> It says:
> "We are willing to help you produce those technical representation. If you
> have started the formal process to request being added to the Mozilla root
> store, and have attached your root to a bugzilla bug, you may ask us to
> produce it for you."
> 
> Could you please provide us this text file?

Please see the attached file. I used the certifiate identified by the SHA1 fingerprint contained in the file.

Comment 40

[Mert Özarar]

I have tried the same scenario with cert8.db yet no problem occured on my browser. Please check out my last comment (number 40) about the subject.

(In reply to Kathleen Wilson from comment #37)
> (In reply to Kathleen Wilson from comment #35)
> > I am getting intermittent errors with the test website
> > https://evssl.turktrust.com.tr/
> >
> 
> I just tried again several times and got the following error:
> 
> An error occurred during a connection to evssl.turktrust.com.tr.
> The signer of the OCSP response is not authorized to give status for this
> certificate.
> (Error code: sec_error_ocsp_unauthorized_response)
> 
> I have manually imported this root:
> http://www.turktrust.com.tr/sertifikalar/
> TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi_s3.crt

Comment 41

[Mert Özarar]

The current certificate hierarchy regarding the EV-SSL certificates and the OCSP responses is as follows:

At the top, we have the self signed root with CN = "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı" and issue date 25.12.2007.

Signed by the root, we have the EV-SSL Subroot with CN = "TÜRKTRUST EV SSL Sunucu Sertifikası Hizmetleri H3 - Sürüm 2" and issue date 25.01.2012.

Signed by the root, we also have the OCSP Responder certificate with CN = "TÜRKTRUST OCSP - Sertifika Durum Protokolü Hizmetleri" and issue date 28.09.2011.

Our EV-SSL certificates are signed by the EV-SL Subroot.

So, the OCSP responses for the EV-SSL certificates are signed by "their parent's sibling" within the same hierarchy.

Do the controls obligate that the responses to be signed by "their own sibling"? But how about the successful connections then?

Comment 42

[Kathleen Wilson]

Well, I've confirmed that the problem has something to do with OCSP -- I turned off OCSP hard fail, and I was able to successfully browse to https://evssl.turktrust.com.tr/. The intermediate cert was successfully loaded, etc.

Then I turned OCSP hard fail back on, and forced the page to reload and I got the sec_error_ocsp_unauthorized_response error again.

Please make sure you turn on OCSP hard fail to test:
https://wiki.mozilla.org/CA:Recommended_Practices#OCSP

Please also note that Kai has provided the test-ev-root in Comment #39, so that you can perform the EV Testing: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

However, for this test to succeed, OCSP will have to work.
https://wiki.mozilla.org/CA:EV_Revocation_Checking

Comment 43

[Kathleen Wilson]

The test website, https://evssl.turktrust.com.tr/, is working for me now -- I have OCSP enforced and am able to browse to the site without error.

Comment 44

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 45

[Kathleen Wilson]

I am now opening the first public discussion period for this request from TÜRKTRUST to add the “TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” root certificate, turn on the websites and code signing trust bits, and enable EV.

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 [e-mail] 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 “TURKTRUST Additional Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of TÜRKTRUST must promptly respond directly in the discussion thread to all questions that are posted.

Comment 46

[Mert Özarar]

Thanks Kate once again.

I'm ready (as a representative) to respond directly.

Regards,

Mert

Comment 47

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate 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 the request to add the “TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” root certificate, turn on the websites and code signing trust bits, and enable EV.

Section 4 [Technical]. I am not aware of instances where TÜRKTRUST has 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]. TÜRKTRUST appears to provide a service relevant to Mozilla users; it is a commercial CA operating in the Republic of 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 and CPS, which are provided in English.


Document Repository: http://www.turktrust.com.tr/en/bilgideposu.html
CP: http://www.turktrust.com.tr/en/files/bilgidepo/TURKTRUST_CP_V-05_%5BEN%5D_(01.11.2011).pdf
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=612540

Section 7 [Validation]. TÜRKTRUST appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Not applicable, not requesting the email trust bit.

* SSL: As per section 3.2 of the CPS, TÜRKTRUST uses an email challenge-response mechanism to confirm the ownership/control of the domain name. For certificates issued to organizations, TÜRKTRUST also validates the organization’s identity, the identity of the organization's representative and his or her authorization to request the certificate.

* Code:  As per section 3.2 of the CPS, object signing certificates are issued to organizations for which TÜRKTRUST has verified the organization’s identity, the identity of the organization's representative and his or her authorization to request the certificate.

Section 15 [Certificate Hierarchy]. 
This is an offline root with internally-operated subordinate CAs which sign end-entity certificates. 

* Both CRL and OCSP are provided 
http://ocsp.turktrust.com.tr
http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl
http://www.turktrust.com.tr/sil/TURKTRUST_SSL_SIL_s3.crl
http://www.turktrust.com.tr/sil/TURKTRUST_EV_SSL_H3_S2.crl
CPS Section 4.10.1: TURKTRUST publishes CRL twice a day within 12 (twelve) hour intervals with a validity period of 24 (twentyfour) hours even if there is no change in the status of certificates.

Sections 9-11 [Audit]. Audits are performed by the Turkish Information and Communication Technologies Authority (ICTA) and the BSI Group The Netherlands B.V. according to the ETSI TS 101 456 and ETSI TS 102 042 - SSL NCP & EV-CP criteria. TURKTRUST is listed as an Electronic Certificate Service Provider and a statement from ICTA is provided here: http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/eshs.php
The ETSI certificate from BSI was attached to the bug,
https://bugzilla.mozilla.org/attachment.cgi?id=585759.
TURKTRUST is also listed as a certified provider on the BSI website, and can be found using “ETS 019” as the Certificate Number:
http://www.bsigroup.com/en/Assessment-and-certification-services/Client-directory/CertificateClient-Directory-Search/

Based on this assessment I intend to approve this request to add the “TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” root certificate, turn on the websites and code signing trust bits, and enable EV.

Note: Before I create the PSM bug for EV, TURKTRUST needs to confirm completion of the EV Testing as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Kai provided the test-ev-root file in Comment #39.

Comment 48

[Kathleen Wilson]

To the representatives of TURKTRUST: 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.

As per the summary in Comment #47, and on behalf of Mozilla I approve this request from TURKTRUST to include the following root certificate in Mozilla:

** TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı (websites, code signing), enable EV.

I will file the NSS bug to include the new root cert.

Before I create the PSM bug for EV enablement, TURKTRUST needs to confirm completion of the EV Testing as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Kai provided the test-ev-root file in Comment #39.

Comment 49

[Kathleen Wilson]

I have filed bug #768547 against NSS to include the new root. I will file the PSM bug after the EV testing has been completed.

Comment 50

[Mert Özarar]

TURKTRUST confirms the completion of the EV Testing as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

You can find the attached snapshot for green bar on the test site.

Comment 51

[Mert Özarar]

Attachment: Green Bar on the Test Site for PSM Easy Testing

Comment 52

[Kathleen Wilson]

I have filed bug #768547 against NSS and bug #788321 against PSM for the actual changes.

Comment 53

[Ben Bucksch (:BenB)]

http://www.h-online.com/security/news/item/Fatal-error-leads-TURKTRUST-to-issue-dangerous-SSL-certificates-1777291.html

Comment 54

[David E. Ross]

Very recently, problems were reported regarding TÜRKTRUST, indicating a lapse in proper operations.  An intermediate certificate was issued in lieu of a subscriber certificate.  

Will the insertion into the NSS database of the certificate addressed in this bug report be put on hold?

Comment 55

[Ben Bucksch (:BenB)]

Yes, see
https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/

However, the certs from bug 380635 seem to remain. This doesn't make much sense.