380635 - add TURKTRUST root CA certificates

Status: RESOLVED FIXED

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

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

This bug report has been completed to fulfill the formality for adding TURKTRUST root CA certificates to Mozilla software certificate stores.

TÜRKTRUST Bilgi, İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (TÜRKTRUST Information Security Services, Inc.) is established as a corporate company for providing qualified electronic certificates as well as SSL or other certificate types and related services in Turkey. TÜRKTRUST heavily invested in the infrastructure; namely building, personnel, hardware, software, etc., and successfully operates its CA processes since July 2005. 

Regarding the related legislation, Electronic Signature Law of Turkey (No. 5070) has passed the parliament approval on January 24, 2004, and enacted after 6 months of the parliament approval. The law is based on the EU Directive on Electronic Signatures of 1999, which presupposes a free market regulated by a Regulatory Body. The Telecommunications Authority of Turkey (TK -  http://www.tk.gov.tr) is depicted as the regulatory body by the law. TK is thus responsible for publishing the administrative and technical ordinances, and implementing necessary audits to allow the operation of a certificate service provider as a qualified certificate issuer. Please check the link http://www.tk.gov.tr/eimza/eshs.htm at TK’s web site to see the list of approved certificate service providers in Turkey. 

TÜRKTRUST root and sub-root certificates are recognized by Microsoft products since the year end of 2005 through the Authority Information Access (AIA) path of the related certificates. Our company contact information is as follows:

TÜRKTRUST Bilgi, İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. 
(TÜRKTRUST Data, Communication and Information Security Services, Inc.)
Address: Hollanda Cad. 62. Sokak No.7 Yıldız Çankaya ANKARA 06550 TURKEY
Phone: [phone]
Fax: [phone]
http://www.turktrust.com.tr

We want to submit two root CA certificates. Our certificates (the two mentioned root certificates and their related subroot certificates) and Certificate Practice Statement can be obtained from the corresponding attachments.

The information that you want as a summary is explained below:

CA Details 
------------------- 
CA Name: TÜRKTRUST Root CA
Website:  http://www.turktrust.com.tr
General nature: Private Sector
Primary geographical area(s) served: Republic of Turkey
Number and type of subordinate CAs: 4 subroots used for in-house facilities
Audit Type (WebTrust, ETSI etc.): Audit and Formal Approval of Telecommunications Authority of Turkey 
Auditor: Turkish Telecommunications Authority
Auditor Website: www.tk.gov.tr
Audit Document URL(s): Attached (has already used for Microsoft Application)

Certificate Details 
------------------- 

1. Certificate 1
Certificate Name: TURKTRUST_Root_1
Summary Paragraph, including the following: N/A
Certificate HTTP URL (on CA website):
http://www.turktrust.com.tr/sertifikalar/kok_s2.crt 
Version: V3 
SHA1 Fingerprint: 79 98 a3 08 e1 4d 65 85 e6 c2 1e 15 3a 71 9f ba 5a d3 4a d9
MD5 Fingerprint: N/A 
Modulus Length (a.k.a. "key length"): 2048 bits 
Valid From (YYYY-MM-DD): 2005-05-13 
Valid To (YYYY-MM-DD): 2015-03-22 
OCSP URL: http://ocsp.turktrust.com.tr
Class (domain-validated, identity-validated or EV): Both Domain-Validated and
Identity-Validated 
Certificate Policy URL: http://www.turktrust.com.tr/pdf/TURKTRUST_SI_S-01.pdf 
CPS URL:  http://www.turktrust.com.tr/pdf/TURKTRUST_SUE_S-01.pdf 
Requested Trust Indicators (email and/or SSL and/or code): Code signing,
Timestamping, Server authentication, Client authentication, Secure Email, OCSP 

------------------- 
2. Certificate 2
Certificate Name: TURKTRUST_Root_2
Summary Paragraph, including the following: N/A
Certificate HTTP URL (on CA website):
http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika _Hizmet_Saglayicisi.crt    
Version: V3 
SHA1 Fingerprint: b4 35 d4 e1 11 9d 1c 66 90 a7 49 eb b3 94 bd 63 7b a7 82 b7
MD5 Fingerprint: N/A 
Modulus Length (a.k.a. "key length"): 2048 bits 
Valid From (YYYY-MM-DD): 2005-07-11 
Valid To (YYYY-MM-DD): 2015-09-16
OCSP URL: http://ocsp.turktrust.com.tr
Class (domain-validated, identity-validated or EV): Both Domain-Validated and
Identity-Validated
Certificate Policy URL: http://www.turktrust.com.tr/pdf/TURKTRUST_SI_S-01.pdf 
CPS URL:  http://www.turktrust.com.tr/pdf/TURKTRUST_SUE_S-01.pdf 
Requested Trust Indicators (email and/or SSL and/or code): Code signing,
Timestamping, Server authentication, Client authentication, Secure Email, OCSP 



Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mert Özarar]

Attachment: TURKTRUST CA Root Certificate 1

Comment 2

[Mert Özarar]

Attachment: TURKTRUST CA Root Certificate 2

Comment 3

[Mert Özarar]

Attachment: Communique on Electronic Signature (Turkish legislation)

Comment 4

[Mert Özarar]

Attachment: Turkish Electronic Signature Law

Comment 5

[Mert Özarar]

Attachment: Ordinance on Electronic Signature (Turkish legislation)

Comment 6

[Mert Özarar]

Attachment: TURKTRUST Certificate Practices Statement

Comment 7

[Mert Özarar]

Attachment: Letter of Official CA Statement for TURKTRUST

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Shortened summary.

Comment 9

[Gervase Markham [:gerv]]

Hi Mert,

Some questions:

- Is the "Letter of Official CA Statement" available from the website of the auditor (The Turkish Telecommunications Authority)?

- Do you have CRLs for your roots? If so, what are their HTTP URLs?

- Are you sure you want your roots to be named "TURKTRUST_Root_1" and "TURKTRUST_Root_2"? Common practice is to use spaces, not underscores.

- Are the two roots used for distinct uses, or not?

Gerv

Comment 10

[Mert Özarar]

- Is the "Letter of Official CA Statement" available from the website of the
auditor (The Turkish Telecommunications Authority)?
* "http://www.tk.gov.tr/eimza/eshs.htm" give the list of CAs in Turkey
audited by the Turkish Telecommunications Authority. It says that,
TURKTRUST started its facilities on 16.07.2005 while applied on
13.05.2005 to be a legal CA. Their status is active and the facilities
are going on.

- Do you have CRLs for your roots? If so, what are their HTTP URLs?
* "http://www.turktrust.com.tr/crl_ain.jsp" gives the URL for CRLs for
root 1 and 2, respectively.

- Are you sure you want your roots to be named "TURKTRUST_Root_1" and
"TURKTRUST_Root_2"? Common practice is to use spaces, not underscores.
* We want to rename them as "TURKTRUST Certificate Services Provider
Root 1" and
"TURKTRUST Certificate Services Provider Root 2" as in common practice.

- Are the two roots used for distinct uses, or not?
* No, root 2 is the extension of root 1 to which new features were
added. There are a limited number of certficates given from root 1
while root 2 is heavily used for our certificate services.
(In reply to comment #9)
> Hi Mert,
> 
> Some questions:
> 
> - Is the "Letter of Official CA Statement" available from the website of the
> auditor (The Turkish Telecommunications Authority)?
> 
> - Do you have CRLs for your roots? If so, what are their HTTP URLs?
> 
> - Are you sure you want your roots to be named "TURKTRUST_Root_1" and
> "TURKTRUST_Root_2"? Common practice is to use spaces, not underscores.
> 
> - Are the two roots used for distinct uses, or not?
> 
> Gerv
> 

Comment 11

[Gervase Markham [:gerv]]

(In reply to comment #10)
> * "http://www.tk.gov.tr/eimza/eshs.htm" give the list of CAs in Turkey
> audited by the Turkish Telecommunications Authority. It says that,
> TURKTRUST started its facilities on 16.07.2005 while applied on
> 13.05.2005 to be a legal CA. Their status is active and the facilities
> are going on.

Right :-) But the letter you attached says "this letter is to inform the public". Does it perform that function by having you email scans of it to people? Or is it actually posted publicly? 

I have gathered together all the other information you have provided, and placed it in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/
(This may take a few hours to update.)

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration.

If your CA or certificate does not have a summary paragraph at the top of the entry, please feel free to provide one. Note: these paragraphs are not supposed to be marketing statements :-)

Gerv

Comment 12

[Mert Özarar]

We -confirm- that our CA information is correct. Moreover, we have started official correspondence with Turkish Telecommunications Authority to publish the letter in their web domain. In a near future, this will take effect.
Should we need to provide a summary paragraph if there is no marketing? :-)

(In reply to comment #11)
> (In reply to comment #10)
> > * "http://www.tk.gov.tr/eimza/eshs.htm" give the list of CAs in Turkey
> > audited by the Turkish Telecommunications Authority. It says that,
> > TURKTRUST started its facilities on 16.07.2005 while applied on
> > 13.05.2005 to be a legal CA. Their status is active and the facilities
> > are going on.
> 
> Right :-) But the letter you attached says "this letter is to inform the
> public". Does it perform that function by having you email scans of it to
> people? Or is it actually posted publicly? 
> 
> I have gathered together all the other information you have provided, and
> placed it in the "pending" CA root certificate request list, which is here:
> http://www.mozilla.org/projects/security/certs/pending/
> (This may take a few hours to update.)
> 
> Please confirm that the information for your CA is correct, and add a comment
> to this bug to that effect. Once you have done that, your application will turn
> "green" and be ready for consideration.
> 
> If your CA or certificate does not have a summary paragraph at the top of the
> entry, please feel free to provide one. Note: these paragraphs are not supposed
> to be marketing statements :-)
> 
> Gerv
> 

Comment 13

[Mert Özarar]

Form now on, we have agreed with Turkish Telecommunications Authority to publish the official certification authorities both in Turkish and English, to be known by international prospectors as well.
The target URL is: http://www.tk.gov.tr/eimza/eshs.htm
We expect that we have fulfilled the requirements that you are looking for.

(In reply to comment #12)
> We -confirm- that our CA information is correct. Moreover, we have started
> official correspondence with Turkish Telecommunications Authority to publish
> the letter in their web domain. In a near future, this will take effect.
> Should we need to provide a summary paragraph if there is no marketing? :-)
> 
> (In reply to comment #11)
> > (In reply to comment #10)
> > > * "http://www.tk.gov.tr/eimza/eshs.htm" give the list of CAs in Turkey
> > > audited by the Turkish Telecommunications Authority. It says that,
> > > TURKTRUST started its facilities on 16.07.2005 while applied on
> > > 13.05.2005 to be a legal CA. Their status is active and the facilities
> > > are going on.
> > 
> > Right :-) But the letter you attached says "this letter is to inform the
> > public". Does it perform that function by having you email scans of it to
> > people? Or is it actually posted publicly? 
> > 
> > I have gathered together all the other information you have provided, and
> > placed it in the "pending" CA root certificate request list, which is here:
> > http://www.mozilla.org/projects/security/certs/pending/
> > (This may take a few hours to update.)
> > 
> > Please confirm that the information for your CA is correct, and add a comment
> > to this bug to that effect. Once you have done that, your application will turn
> > "green" and be ready for consideration.
> > 
> > If your CA or certificate does not have a summary paragraph at the top of the
> > entry, please feel free to provide one. Note: these paragraphs are not supposed
> > to be marketing statements :-)
> > 
> > Gerv
> > 
> 

Comment 14

[Gervase Markham [:gerv]]

OK. I have begun my evaluation, and I have some questions (or repeated questions):

- You state that "Moreover, we have started official correspondence with Turkish Telecommunications Authority to publish the letter in their web domain." This is very good news. Please let me know the URL of the published letter when you have it.

- How often do you issue CRLs for subscriber (end-entity) certificates?

- Do you have a diagram of your certificate hierarchy (roots, intermediates etc.)?

- Your CP/CPS and/or other documents are not in English. Assuming they are not available in English (please let me know if they are), then I have to have particular parts translated. As having documents translated and reading approximate translations is a tedious task, I hope you will be able to help me in narrowing down which parts to read.

When I read a CP/CPS, I am looking to see if the practices of the CA satisfy the criteria in our CA Certificate Policy:
http://www.mozilla.org/projects/security/certs/policy/

Specifically, I look for:

- Which exact section contains an undertaking to confirm that the applicant has control of the email address before issuing them an email certificate?

- Which exact section contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate?

- (If applicable) Which exact section contains an undertaking that the applicant's identity is strongly validated before issuing them a code signing certificate?

Can you point me at the correct sections of your documents for each of these cases?

Gerv

Comment 15

[Mert Özarar]

Here are the answers for the listed questions:

- We have finished the process for publishing the letter in Turkish Telecommunications Authority's web domain so we have waited to reply until that. The exact URL is: http://www.tk.gov.tr/eimza/doc/aciklama/tt.doc

- CRLs for subscriber (end-entity) certificates are issued daily. 

- We have attached two diagrams as JPG files for both root hiearchies.

- We have attached the English version of CPS. Since CPS concerns the question "how?" and CP concerns "what?", it is obviously more desirable to handle and investigate CPS rather than CP for our case. CPS contains the more or less the content of the CP as well. We have no doubt that English-CPS shall be sufficient for further analysis. Moreover, if you have any questions regarding the parts related to CP but does not exist in CPS, the English version of the target section will be supplied. As you imagine, the sworn translation of CP is going to take tedious effort and time. Besides, we provide the Letter of Commitment (subscriber agreement in the CA jargon) in English to put the qualified certificate owner at ease. The LoC is also attached to the bug report's attachments.

- We have attached the English version of the Qualified Electronic Signature Application Form for single year usage. In this form, the qualified certificate owner candidate provide and fill the e-mail address under authentication via face-to-face and signs the form with pen. This completes the civil procedure and suitable for legislation.

- "Section 3.2.2 Authentication of Organizational Identitiy" in CPS contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate.

- Code signing operations and checks are going to be available with the coming versions of the CPS.

Regards,
Mert ÖZARAR

(In reply to comment #14)
> OK. I have begun my evaluation, and I have some questions (or repeated
> questions):
> 
> - You state that "Moreover, we have started official correspondence with
> Turkish Telecommunications Authority to publish the letter in their web
> domain." This is very good news. Please let me know the URL of the published
> letter when you have it.
> 
> - How often do you issue CRLs for subscriber (end-entity) certificates?
> 
> - Do you have a diagram of your certificate hierarchy (roots, intermediates
> etc.)?
> 
> - Your CP/CPS and/or other documents are not in English. Assuming they are not
> available in English (please let me know if they are), then I have to have
> particular parts translated. As having documents translated and reading
> approximate translations is a tedious task, I hope you will be able to help me
> in narrowing down which parts to read.
> 
> When I read a CP/CPS, I am looking to see if the practices of the CA satisfy
> the criteria in our CA Certificate Policy:
> http://www.mozilla.org/projects/security/certs/policy/
> 
> Specifically, I look for:
> 
> - Which exact section contains an undertaking to confirm that the applicant has
> control of the email address before issuing them an email certificate?
> 
> - Which exact section contains an undertaking to confirm that the application
> has control of a domain name before issuing them an SSL certificate?
> 
> - (If applicable) Which exact section contains an undertaking that the
> applicant's identity is strongly validated before issuing them a code signing
> certificate?
> 
> Can you point me at the correct sections of your documents for each of these
> cases?
> 
> Gerv
> 

Comment 16

[Mert Özarar]

Attachment: The first root hierarchy of TURKTRUST

Comment 17

[Mert Özarar]

Attachment: The second hierarchy of TURKTRUST

Comment 18

[Mert Özarar]

Attachment: The English version of TURKTRUST Certificate Practices Statement

Comment 19

[Mert Özarar]

Attachment: TURKTRUST - Qualified Electronic Certificate (QEC) Application Form

Comment 20

[Mert Özarar]

Attachment: TURKTRUST QEC Letter of Commitment

Comment 21

[Gervase Markham [:gerv]]

(In reply to comment #15)
> Here are the answers for the listed questions:
> 
> - We have finished the process for publishing the letter in Turkish
> Telecommunications Authority's web domain so we have waited to reply until
> that. The exact URL is: http://www.tk.gov.tr/eimza/doc/aciklama/tt.doc

Well, I would prefer it if they had put up a copy of the letter which you
already attached (attachment 264748 [details]) but I guess this will do.

Thank you for the English translation of your CPS. That is very helpful indeed. However, I can't find the details I need, as outlined in the last six paragraphs of comment #14. Does your CPS talk about those points? If not, perhaps you could explain what your procedures are and how they meet those criteria. Then we can discuss updating the CPS to include that information.

Gerv

Comment 22

[Mert Özarar]

We do not prefer to include the operational details in our CPS document. Our CP mainly explains "what" we do and our CPS explains "how" we do those, to a specific extent. As a principle, our CPS gives information about all our CA processes and how we undergo the related primary functions.
 
However, the more detailed operational steps are documented in our "procedures" and related "instructions". Several "forms" are used to keep the procedural records. We use this documentaiton  as part of our ISO 27001 documentation and CP and CPS are at the top of our CA documentation pyramid.
 
Hence, some of the questions you ask have their answers in those operational documents and we do not publicize them through our CP and CPS, as they contain company specific and sensitive information as well.
 
Coming to the six paragraphs of your comment #14, we tried to answer them before according to our operational procedures, some of which are not detailed in our CPS.

Regards,
Mert ÖZARAR

(In reply to comment #21)
> (In reply to comment #15)
> > Here are the answers for the listed questions:
> > 
> > - We have finished the process for publishing the letter in Turkish
> > Telecommunications Authority's web domain so we have waited to reply until
> > that. The exact URL is: http://www.tk.gov.tr/eimza/doc/aciklama/tt.doc
> 
> Well, I would prefer it if they had put up a copy of the letter which you
> already attached (attachment 264748 [details]) but I guess this will do.
> 
> Thank you for the English translation of your CPS. That is very helpful indeed.
> However, I can't find the details I need, as outlined in the last six
> paragraphs of comment #14. Does your CPS talk about those points? If not,
> perhaps you could explain what your procedures are and how they meet those
> criteria. Then we can discuss updating the CPS to include that information.
> 
> Gerv
> 

Comment 23

[Gervase Markham [:gerv]]

I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv

Comment 24

[Gervase Markham [:gerv]]

Mr Özarar,

That presents a problem for us. We cannot accept roots into our root program unless there has been a public commitment on the part of their owners to meet the (fairly basic) minimum vetting criteria in section 7 of the policy. This commitment needs to be in a document which is binding - so that usually means a CP or CPS.

Gerv

Comment 25

[Mert Özarar]

We think it is clear how we control the entity submitting the request controls the email account associated with the email address. However, the content and quality of the documentation of this specific subject is quite fuzzy in our CPS.  
We have already decided to rewrite/extend our CPS in a way that it fulfills all the requirements and completes the criterias and points that are not clear enoough. We are going to add the exact procedures for minimum vetting criterias for both Qualified, SSL and Object Signing Certificates. Our tentative additions/modifications include:

1. E-mail addresses for Qualified Electronic Signatures are verified through the declaratory statement of the applicant to our application form and signed with handwritten signature of the applicant. (Besides, other sufficient information like home address, phone number, etc. are grepped in the same way) 

2. In SSL certificate applications, in addition to corporate verification, the ownership of the domain name is also verified.

3. For Object Signing case, the related address and other information are taken by declaration and corporate verification.

--We would be happy if you EXACTLY AND URGENTLY mention what we have to write additionally (via specific statements) unless it is clear enough.-- 

Best regards,
Mert ÖZARAR

(In reply to comment #24)
> Mr Özarar,
> 
> That presents a problem for us. We cannot accept roots into our root program
> unless there has been a public commitment on the part of their owners to meet
> the (fairly basic) minimum vetting criteria in section 7 of the policy. This
> commitment needs to be in a document which is binding - so that usually means a
> CP or CPS.
> 
> Gerv
> 

Comment 26

[Mert Özarar]

Mr. Markham,

The version 2 of our CPS is ready and uploaded to the attachments ("finalCPS.doc"). Please control it for specific points. I leave the "track changes" open to ease your cross-check.

--We would be happy if you EXACTLY AND URGENTLY mention what we have to write
additionally (via specific statements) unless it is clear enough.--

Best regards,
Mert ÖZARAR

Comment 27

[Mert Özarar]

Attachment: Second Version of English CPS

Comment 28

[Gervase Markham [:gerv]]

(In reply to comment #25)
> 1. E-mail addresses for Qualified Electronic Signatures are verified through
> the declaratory statement of the applicant to our application form and signed
> with handwritten signature of the applicant. (Besides, other sufficient
> information like home address, phone number, etc. are grepped in the same way)

But a fraudster might be happy to agree to anything. You need to check that they actually have control of the email account, by sending them email and getting a response. If your procedures do not include this step, they should. Missing it out is a hole in the procedure.
 
> 2. In SSL certificate applications, in addition to corporate verification, the
> ownership of the domain name is also verified.

This is section 4.2.1, right? This still seems a bit unclear. What exactly are you checking? That the data from the WHOIS record matches the applicant? What happens if it doesn't? Is the application refused?

> 3. For Object Signing case, the related address and other information are 
> taken
> by declaration and corporate verification.

Are all Object Signing certificates qualified? Most of the language in the CPS which takes about strong verification has a "for qualified electronic certificates" qualifier.

> --We would be happy if you EXACTLY AND URGENTLY mention what we have to write
> additionally (via specific statements) unless it is clear enough.-- 

It's not a case of you writing what makes me happy, it's a case of you writing down what you do, and me deciding whether what you do makes me happy! :-)

Also, what are these "test certificates" you mention in the CPS? What prevents a criminal getting hold of one of these (taking advantage of the much-reduced checking) and using it for spoofing?

Gerv

Comment 29

[Mert Özarar]

Dear Mr. Markham,
 
We want to continue our relations with Mozilla in an optimistic way so we have listed our cordial answers for somewhat problematic cases in below:
 
1. For the e-mail verification case:
 
To control of the email account, by sending them email and getting a response is still not a full secure way of checking out the verification of e-mail address. If so, why do we need digital signatures or multilevel authentication schemes other than username/password tuple?
In Turkish Digital Signature Law, there is no problem with a verification through the declaratory statement of the applicant to our application form and signed with handwritten signature of the applicant. Do we have to use a challenge mechanism even though it is not secure enough? Is it obligatory for Mozilla? or do all the CAs use the same procedure?
 
2. In section 4.2.1 of our CPS v2.0,
 
"When processing a server certificate application, the domain name that belongs to the server, the server’s name and the name of the domain owner and personal information for the server administrator should be verified by TÜRKTRUST’s registration authorities. The information published by authorized resources are used for the verification of the domain name ownership. (www.nic.tr records for domain names with “.tr” extension, international resources are based on for other domain names)"
We control whether the data supplied by the applicant are consistent with previous records or not, via specific services from specific corporations.
The application is refused for the negative case.
 
3. None of our object signing certificates are qualified yet we apply similar procedures as QEC during application phase.
 
4. You understand trial(i.e. test) certificates wrong I guess. The trial certificates are given without fee. They are not valid under Law since they are not qualified thus spoofing does not bother. 
 
p.s. You misunderstood our message related with URGENCY and EXACTNESS by the way. Your reply-mails dates' to our messages can explain what we mean to be urgent and the bottleneck at e-mail verification case explains the exactness. We are NOT going to be happy even though the managerial processes are completed, on the contrary.
 
Regards,
 
Mert ÖZARAR

Comment 30

[Mert Özarar]

Dear Mr. Markham,

Does there exist an improvement for your feedback that we are waiting for a month time? Is it better to arrange a phone call? Our corporate customers (which is about companies) and personal customers are persistenly asking for us the usage of their (SSL) certificates with Firefox and Thunderbird. We do not want to forward them to use Microsoft products since we have completed the same process in 2 months time. 
The control procedure lasts quite a long time and we do not understand why we stuck at such a point like e-mail verification which is confirmed by Turkish Government. 
Please keep in touch with me immediately. You can give your phone number to me or call me from [[phone]].

Best regards,

Mert ÖZARAR

Comment 31

[Gervase Markham [:gerv]]

Mr Ozarar,

I apologise for the delay. Frank Hecker is taking over the root program from me, and I've been handing it over. I'm sure you will hear from him soon.

Gerv

Comment 32

[Mert Özarar]

Attachment: Third Version of TURKTRUST-CPS (email verification revised) (MSWord document)

Comment 33

[Mert Özarar]

Third Version of TURKTRUST-CPS (email verification revised) have just attached

Comment 34

[Frank Hecker]

(In reply to comment #33)
> Third Version of TURKTRUST-CPS (email verification revised) have just attached

Is this version available on the TÜRKTRUST web site? It would be much easier for people to download it from there instead of from Bugzilla. Could you please put a copy on your web site, in PDF format?

Comment 35

[Frank Hecker]

I'm accepting this bug, since I'm now reviewing this application, not Gerv.

Comment 36

[Frank Hecker]

Re-assigning to me (didn't work first time).

Comment 37

[Frank Hecker]

I'm currently reviewing TÜRKTRUST's application, as per sections 1, 5 and
15 of the official CA policy at:
<http://www.mozilla.org/projects/security/certs/policy/>. I apologize for any
delays on my part in doing the review.

Here follows my *preliminary* assessment as of today. If anyone sees any factual errors, please point them out.

NOTE: This is *not* my final review. As discussed below, there are some minor issues I would like to see resolved before I announce my intent to approve this application. [Mr. Özarar, please see the notes and questions to you below, enclosed in square brackets.]

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by TÜRKTRUST, or 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. Its policies are documented in its CPS, an English version of which TÜRKTRUST has made available to us.

[NOTE: It would be better if the English version of the CPS were available directly from the TÜRKTRUST web site, in PDF format. That would help confirm that it is indeed an official TÜRKTRUST document. Also note that there is a typographical error in the v03 CPS: the page headers identify the version as 02.]

* Email: For certificates issued to individuals, TÜRKTRUST verifies both identity and control of the email account associated with the email address referenced in the certificate. (See section 3.2.3 in the TÜRKTRUST CPS v03.)

* SSL: For SSL certificates issued to organizations, TÜRKTRUST validates the identity of the organization's representative and his or her authorization to request the certificate, and also verifies ownership of the associated domain. (See sections 3.2.2 and 4.2.1 in the TÜRKTRUST CPS v03.)

* Code: For object signing certificates issued to organizations TÜRKTRUST verifies the organizational identity. (See section 3.1.2 of the TÜRKTRUST CPS v03.]

[NOTE: It appears that TÜRKTRUST issues object signing certificates only to organizations, not to individuals. Is this correct?]

Section 8-10 [Audit]. TÜRKTRUST has successfully completed an independent audit
using the ETSI TS 101.456 criteria. The audit was done by the Turkish Telecommunications Authority (Telekomünikasyon Kurumu) <http://www.tk.gov.tr/>, an agency of the Turkish government. Attestation of the successful completion of the audit is in the form of 1) inclusion of TÜRKTRUST in a list of accredited CAs on the Telecommunications Authority web site:

  http://www.tk.gov.tr/eimza/eshs.htm

and 2) a letter published on the Telecommunications Authority web site:

  http://www.tk.gov.tr/eimza/doc/aciklama/tt.doc

[NOTE: The letter from the Telecommunications Authority says that "TA then conducts periodical and non-periodical audits to assure the continuity of conformance with the law and the ordinances." Once the initial audit is completed (which for TÜRKTRUST was 15 July 2005), how frequently does the Telecommunications Authority conduct the subsequent periodic audits?]

Section 13 [Certificate Hierarchy]. TÜRKTRUST has two different root
CAs. The first root CA has two subordinate CAs, one for qualified certificates and one for SSL certificates. The second root CA has three subordinate CAs, for qualified certificates, SSL certificates, and object signing certificates respectively.

Other: TÜRKTRUST issues CRLs (on a 24-hour schedule) and also has an OCSP
responder.

After I receive a response to my notes and questions listed above, I will proceed to make my final review of TÜRKTRUST's application.

Comment 38

[Mert Özarar]

Dear Mr. Hecker,

Thank you very much for your invaluable comments on our application. After your involvement to our review, we believe that this process is going to be successfully completed. Here are our answers to your questions/remarks:
--
Remark:
[NOTE: It would be better if the English version of the CPS were available
directly from the TÜRKTRUST web site, in PDF format. That would help confirm
that it is indeed an official TÜRKTRUST document. Also note that there is a
typographical error in the v03 CPS: the page headers identify the version as
02.]
Answer:
You are definitely right. Here is the URL of the CPS:
http://www.turktrust.com.tr/pdf/cps_third.pdf 
It can be reached under Repository->TurkTrust Docs (Bilgi Deposu->TurkTrust Dokumanlari) (in Turkish). I have changed the typographical error in the v03 CPS as well before converting to pdf. Sorry for the typo ;)
--
Question:
[NOTE: It appears that TÜRKTRUST issues object signing certificates only to
organizations, not to individuals. Is this correct?]
Answer:
Yes, only to organizations.
--
Question:
[NOTE: The letter from the Telecommunications Authority says that "TA then
conducts periodical and non-periodical audits to assure the continuity of
conformance with the law and the ordinances." Once the initial audit is
completed (which for TÜRKTRUST was 15 July 2005), how frequently does the
Telecommunications Authority conduct the subsequent periodic audits?]
Answer:
Telecommunications Authority conducts periodic audits ANNUALLY. We have recently passed 2007's audit at the beginning of June. 

Best regards, we are hoping to conclude the review process and loooking forward to see us in Mozilla trusted CA stores.

Mert ÖZARAR

Comment 39

[Frank Hecker]

I have now completed my review of TÜRKTRUST's application, as per sections 1, 5 and 15 of the official CA policy at:
<http://www.mozilla.org/projects/security/certs/policy/>. Again I apologize for any delays on my part in doing the review.

Here follows my final assessment. If anyone sees any factual errors, please point them out.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by TÜRKTRUST, or 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. Its policies are documented in its CPS, an English version of which is available on the TÜRKTRUST web site:

  http://www.turktrust.com.tr/pdf/cps_third.pdf

* Email: For certificates issued to individuals, TÜRKTRUST verifies both identity and control of the email account associated with the email address referenced in the certificate. (See section 3.2.3 in the TÜRKTRUST CPS v03.)

* SSL: For SSL certificates issued to organizations, TÜRKTRUST validates the identity of the organization's representative and his or her authorization to request the certificate, and also verifies ownership of the associated domain.
(See sections 3.2.2 and 4.2.1 in the TÜRKTRUST CPS v03.)

* Code: For object signing certificates issued to organizations TÜRKTRUST verifies the organizational identity. (See section 3.1.2 of the TÜRKTRUST CPS
v03.) (Note that TÜRKTRUST issues object signing certificates only to organizations, not to individuals.)

Section 8-10 [Audit]. TÜRKTRUST has successfully completed an independent
audit using the ETSI TS 101.456 criteria. The audit was done by the Turkish Telecommunications Authority (Telekomünikasyon Kurumu) <http://www.tk.gov.tr/>, an agency of the Turkish government. Attestation of the successful completion of the audit is in the form of 1) inclusion of TÜRKTRUST in a list of accredited CAs on the Telecommunications Authority web site:

  http://www.tk.gov.tr/eimza/eshs.htm

and 2) contents of a letter published on the Telecommunications Authority web site:

  http://www.tk.gov.tr/eimza/doc/aciklama/tt.doc

(TÜRKTRUST has also provided a scanned copy of the original signed letter as an attachment to this bug. Since the copy was provided by the CA and not by the Telecommunications Authority, I do not consider it to be primary evidence of the audit's completion. However the letter is consistent with the independent evidence provided by the Telecommunications Authority on its web site.)

The Telecommunications Authority conducts audits on an annual basis.

Section 13 [Certificate Hierarchy]. TÜRKTRUST has two different root CAs. The first root CA has two subordinate CAs, one for qualified certificates and one for SSL certificates. The second root CA has three subordinate CAs, for qualified certificates, SSL certificates, and object signing certificates
respectively. The first hierarchy is no longer actively used for issuing certificates; current certificates are used from the CAs in the second hierarchy.

Other: TÜRKTRUST issues CRLs (on a 24-hour schedule) and also has an OCSP responder.

Based on the above information, I am minded to approve the inclusion of the two
TÜRKTRUST root CAs (Roots 1 and 2) in NSS and thence in Firefox and other Mozilla-based products. Before I do, I'm opening up a period of public discussion of this request. I'll post in the mozilla.dev.tech.crypto newsgroup [1] to allow people to make comments. The normal comment period is two weeks, unless issues are brought forth that warrant further discussion and investigation.

[1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable newsreaders at:

  news://news.mozilla.org/mozilla.dev.tech.crypto

via email by subscribing to the associated mailing list:

  https://lists.mozilla.org/listinfo/dev-tech-crypto

and via the web at:

  http://groups.google.com/group/mozilla.dev.tech.crypto/topics

Comment 40

[Nelson Bolyard (seldom reads bugmail)]

If this CA is issuing "trial" certificates without any authentication of 
information listed in the trial certs' subjects, and those trial certs 
appear in a browser to be just as valid as the non-trial certs issued by
that same CA, then that, IMO, is a complete show stopper for this CA. 

It does not matter that, under Turkish law, the trial certs are not valid.
What matters is that the browser cannot tell the difference, and shows to
the browser user the same symbols of secure service in both cases.  

If persons can get "trial" certificates from this CA for (say) www.paypal.com
that appear valid in the browser, and chain up to any of the root CA certs 
attached above, then IMO this CA must NOT be admitted to mozilla's root CA 
cert program until new roots are issued against which those bogus trial 
certificates will not validate.

Comment 41

[Mert Özarar]

I think there was a misunderstanding at so called "trial
certificates". Trial certificates are kind of certificates which are
not valid under Turkish Law. As you suppose, "digital certificate"
concept is quite a new topic for most of the countries except USA or
EU. The past of digital certificates entitled by Turkish Government is
just 2.5 years. We have started to give trial certificates after our
establishment for educational and promotional purposes. People who
have gathered trial certificates can use and learn at the same time
the aim of Public Key Infrastructure. They are NOT in the same
template with "Qualified Electronic Certificates"(QEC). Besides, the
root of the qualified certificates is completely DIFFERENT. 
We -definitely- do not want to add this dedicated trial certificate root to IMO store by the way.

Comment 42

[Mert Özarar]

dear Frank,
I think the period dedicated for "public-comment" has recently been over. Everything is clear except two points (trial certs & non-latin chars). 
For the former one, what do you prefer? should we clearly indicate in our CPS that the root for trial certificates is completely different inclıding its trust hierarchy. Do we suppose to this? Eddy insisted on that yet I think if someone investigates our (English or Turkish) website prospectively, he/she can reach our root certificates from "Repository" (http://www.turktrust.com.tr/e/en51.jsp) and can understand that there are -2- trust hierarchies where neither includes the root certificate for trial certificates. 
For the latter, both Eddy and other guys think that it is a general problem and cannot affect our inclusion process to IMO. The decision of this case should bother all the CAs with non-latin national alphabets and the topic should move to another place in the discussion forum.
In conclusion, what are we going to do next in your directions? If no more further concerns at the end of the two weeks, shall you request to our certificates to the NSS cryptographic library from the NSS developers? We are indeed enthusiastic for the inclusion to IMO since our customers are really looking for it and we have lost quite a lot time.
Best regards,
Mert ÖZARAR

Comment 43

[Frank Hecker]

First, my apologies for the delay in completing work on this bug. As Mert Özarar noted in comment #42, the public comment period for the TÜRKTRUST application has now ended, and it's time to make a final decision.

Regarding the issue of non-Latin characters used in certificates, that issue is a general issue that is outside the scope of the current Mozilla CA certificate policy; therefore in my opinion it does not and should not affect this particular application.

Regarding the issue of trial certificates (as discussed in comment #40 and elsewhere), the problem appears to be that the CPS is written to apply to all of TÜRKTRUST's root CAs, one of which is used to issue trial certificates; that is what accounts for the presence of various statements in the CPS relating to verification procedures, etc., for trial certificates. However as stated in the CPS issuance of trial certificates is under a separate policy than those for qualified and other certificates, and as noted at

  http://www.turktrust.com.tr/e/en51.jsp

trial certificates are issued under a root CA dedicated to that purpose, different from the root CAs which are the subject of this application. I wish that the CPS was more clear on this point, and I have suggested to TÜRKTRUST that it provide more clarity on the trial certificate issue in future versions of the CPS; however based on the information available to us I do not think that the trial certificate issue is relevant for this application.

Since these were the only two remaining issues, I am now approving the TÜRKTRUST root CAs for inclusion, and will proceed to file the necessary NSS bug to that effect. 

Comment 44

[Frank Hecker]

Filed bug 410821 for inclusion of the two TURKTRUST root CA certificates into NSS

Comment 45

[Frank Hecker]

Since bug 410821 is now RESOLVED FIXED, I'm resolving this bug as FIXED as well.

Comment 46

[Ben Bucksch (:BenB)]

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