476428 - Add Turkish E-Guven root CA cert

Status: RESOLVED FIXED

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

Description

[Alpaslan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; tr; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/ 

In Turkey Qualified Electronic Certificate market is growing increasingly in the last couple of years. 
As E-Guven, we are first and leading electronic certificate service provider in Turkey. We provide Mobile, SSL,client and qualified electronic signatures to our clients. Totally we have 80.000 clients in Turkey using our products. 
In last december our government has opened a web site www.turkiye.gov.tr. In this site e-governence services are provided to Turkish citizens. Our qualified certs are also used in this site. 
Nowadays we have received complaints about mozilla users saying that they need to get technical support before using certs in their browsers. So we wanted to get in touch with you and ask to include our root cert in Mozilla browsers. 

Besides these, application providers are increasing in electronic signature market. Including E-Guven certs will help development in Turkey's electronic signature market. 



Reproducible: Always

Steps to Reproduce:
1.
2.
3.



We have accredited from Turkey Government's Information Technologies and Communications Authority 
http://www.tk.gov.tr/eimza/doc/aciklama/eguven.jpg

Our certs are have digital signing, encrypted email, server authentication, non-repudiation key usages. 

We have ISO:27001 certificate for our IT operations.



E-GUVEN ROOT
-----BEGIN CERTIFICATE-----
MIIDtjCCAp6gAwIBAgIQRJmNPMADJ72cdpW56tustTANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJUUjEoMCYGA1UEChMfRWxla3Ryb25payBCaWxnaSBHdXZlbmxp
Z2kgQS5TLjE8MDoGA1UEAxMzZS1HdXZlbiBLb2sgRWxla3Ryb25payBTZXJ0aWZp
a2EgSGl6bWV0IFNhZ2xheWljaXNpMB4XDTA3MDEwNDExMzI0OFoXDTE3MDEwNDEx
MzI0OFowdTELMAkGA1UEBhMCVFIxKDAmBgNVBAoTH0VsZWt0cm9uaWsgQmlsZ2kg
R3V2ZW5saWdpIEEuUy4xPDA6BgNVBAMTM2UtR3V2ZW4gS29rIEVsZWt0cm9uaWsg
U2VydGlmaWthIEhpem1ldCBTYWdsYXlpY2lzaTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMMSIJ6wXgBljU5Gu4Bc6SwGl9XzcslwuedLZYDBS75+PNdU
MZTe1RK6UxYC6lhj71vY8+0qGqpxSKPcEC1fX+tcS5yWCEIlKBHMilpiAVDV6wlT
L/jDj/6z/P2douNffb7tC+Bg62nsM+3YjfsSSYMAyYuXjDtzKjKzEve5TfL0TW3H
5tYmNwjy2f1rXKPlSFxYvEK+A1qBuhw1DADT9SN+cTAIJjjcJRFHLfO6IxClv7wC
90Nex/6wN1CZew+TzuZDLMN+DfIcQ2Zgy2ExR4ejT669VmxMvLz4Bcpk9Ok0oSy1
c+HCPujIyTQlCFzz7abHlJ+tiEMl1+E5YP6sOVkCAwEAAaNCMEAwDgYDVR0PAQH/
BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFJ/uRLOU1fqRTy7ZVZoE
VtstxNulMA0GCSqGSIb3DQEBBQUAA4IBAQB/X7lTW2M9dTLn+sR0GstG30ZpHFLP
qk/CaOv/gKlR6D1id4k9CnU58W5dF4dvaAXBlGzZXd/aslnLpRCKysw5zZ/rTt5S
/wzw9JKp8mxTq5vSR6AfdPebmvEvFZ96ZDAYBzwqD2fK/A+JYZ1lpTzlvBNbCNvj
/+27BrtqBrF6T2XGgv0enIu1De5Iu7i9qgi0+6N8y5/NkHZchpZ4Vwpm+Vganf2X
KWDeEaaQHBkc7gGWIjQ0LpH5t8Qn0Xvmv/uARFoW5evg1Ao4vOSR49XrXMGs3xtq
fJ7lddK2l4fbzIcrQzqECK+rPNv3PGYxhrCdU3nt+CPeQuMtgvEP5fqX
-----END CERTIFICATE-----


EGUVEN MOBILE INT. ROOT
-----BEGIN CERTIFICATE-----
MIIF3jCCBMagAwIBAgIQEJK82kkUSVryvQeCi44OojANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJUUjEoMCYGA1UEChMfRWxla3Ryb25payBCaWxnaSBHdXZlbmxp
Z2kgQS5TLjE8MDoGA1UEAxMzZS1HdXZlbiBLb2sgRWxla3Ryb25payBTZXJ0aWZp
a2EgSGl6bWV0IFNhZ2xheWljaXNpMB4XDTA3MDEwNDExNDEzM1oXDTE2MTIwNDEx
MzUzM1owgYExCzAJBgNVBAYTAlRSMSgwJgYDVQQKEx9FbGVrdHJvbmlrIEJpbGdp
IEd1dmVubGlnaSBBLlMuMUgwRgYDVQQDEz9lLUd1dmVuIE1vYmlsIE5pdGVsaWts
aSBFbGVrdHJvbmlrIFNlcnRpZmlrYSBIaXptZXQgU2FnbGF5aWNpc2kwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAyefVZqGRVG2eS3+T9ztJdZ/UAaJ/
l6aUFBAMHSOZRlo9Mg2kxUwrlbaOcK5zoVsut1LUueIWY+Tvwvinu9QuihjWzj2B
S457k4wc4YHpzD7hhJeRwg4pg8JJ313rpmGLDucQg3fPv/0HEdhb6rAM4uUvJxr+
dfe90NQuYZZT8gis7et9n0GWevM+AjF6Qv8c/f0d02RgJjn7xXMv29i10ySMDIcL
Jw075BvLeQeVIqSXzA+l4LsG6GjQFxtTzG6oLZdtJzHALVtEqEPc6he8DSll4tK7
E5tP3b4e8bwV3SVtAsOCRCllJoUtgJ6HshQfBRzhZXmzLEv5mzwhZWHVAgMBAAGj
ggJbMIICVzB1BggrBgEFBQcBAQRpMGcwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3Nw
Mi5lLWd1dmVuLmNvbS9vY3NwLnh1ZGEwNQYIKwYBBQUHMAKGKWh0dHA6Ly93d3cu
ZS1ndXZlbi5jb20vZG9jdW1lbnRzL0tPSzIuY3J0MA4GA1UdDwEB/wQEAwIBBjAP
BgNVHRMBAf8EBTADAQH/MIIBJQYDVR0gBIIBHDCCARgwggEUBglghhgDAAEBAgEw
ggEFMDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmUtZ3V2ZW4uY29tL2RvY3VtZW50
cy9ORVNVRS5wZGYwgcoGCCsGAQUFBwICMIG9HoG6AEIAdQAgAHMAZQByAHQAaQBm
AGkAawBhACAAaQBsAGUAIABpAGwAZwBpAGwAaQAgAHMAZQByAHQAaQBmAGkAawBh
ACAAdQB5AGcAdQBsAGEAbQBhACAAZQBzAGEAcwBsAGEAcgExAG4BMQAgAG8AawB1
AG0AYQBrACAAaQDnAGkAbgAgAGIAZQBsAGkAcgB0AGkAbABlAG4AIABkAG8AawD8
AG0AYQBuATEAIABhAOcBMQBuATEAegAuMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6
Ly9zaWwuZS1ndXZlbi5jb20vRWxla3Ryb25pa0JpbGdpR3V2ZW5saWdpQVNSb290
L0xhdGVzdENSTC5jcmwwHwYDVR0jBBgwFoAUn+5Es5TV+pFPLtlVmgRW2y3E26Uw
HQYDVR0OBBYEFL+Icd/SFV4NMbC2Mw0o+M2ynB3WMA0GCSqGSIb3DQEBBQUAA4IB
AQCBbm6OkqSVbbx93KYDPBhEKV5zF2xBuq683r2+BDvDx/PCTEdvUM6z6KJ2gDDK
IXzCZu9wl9bsEpIOknfGXWAveM+xz13gFXtw4NahZ7rPrnIqXnUiOvr2K2+VENRa
t9SdqbAIaZjRn8xw4Dd/VmCozmbvbsgK1sBMwsGVPyDxYsqPZ+YD5bZntypixOAA
/GI+7adfaDtbtHifyOoXiaEpH0gZCMnxPJJnnS5lf2nK7k+DGg/0AsHHe9B1Tt7F
Hak6GjO0i76gKA3n9KVW8mE/Zw19tvok+Tm6C7mCjtuLWlEjGdGgaVvJa/p2jew9
q2WUKKGPrBBcBdIJ513BtvvW
-----END CERTIFICATE-----


EGUVEN QUALIFIED ELECTRONIC CERT INT. ROOT

-----BEGIN CERTIFICATE-----
MIIF2DCCBMCgAwIBAgIRAOWbBbm6J6kLD3f4eI3co0MwDQYJKoZIhvcNAQEFBQAw
dTELMAkGA1UEBhMCVFIxKDAmBgNVBAoTH0VsZWt0cm9uaWsgQmlsZ2kgR3V2ZW5s
aWdpIEEuUy4xPDA6BgNVBAMTM2UtR3V2ZW4gS29rIEVsZWt0cm9uaWsgU2VydGlm
aWthIEhpem1ldCBTYWdsYXlpY2lzaTAeFw0wNzAxMDQxMTQ3NTJaFw0xNjEyMDQx
MTM1NTJaMHsxCzAJBgNVBAYTAlRSMSgwJgYDVQQKEx9FbGVrdHJvbmlrIEJpbGdp
IEd1dmVubGlnaSBBLlMuMUIwQAYDVQQDEzllLUd1dmVuIE5pdGVsaWtsaSBFbGVr
dHJvbmlrIFNlcnRpZmlrYSBIaXptZXQgU2FnbGF5aWNpc2kwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCeKO3MARYSTocR2S2Umb0LOkRaWF8VlkObtPBi
WwODoebHBd3UeKD2FDeJDUcisAbQQ4ZpUoBCmSMLfeEOxyG7b4IojCGXloBX+PRW
AlHXXx8GaM5pnvU9wIRXKeA87xCa+1yTm94f0aJDE8EgX4ozAm3eXRyBGPL6jgUe
Oc7Ws3AXr1BMKvapXWUO+h3IewP75rdQU5DttJphUTbcWZ8o41hL+WrMztozaf1U
EXZ6j9XfRWU1tVloiFcnqQH5xY4j1aAeU/a3231C11+PJdmEaVp1cJpZJdr0MqjJ
wjnepWHbGA6Md6jRKfgKWkqkUD+MdNrG1HhpHSDpu81hvhTHAgMBAAGjggJbMIIC
VzB1BggrBgEFBQcBAQRpMGcwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5lLWd1
dmVuLmNvbS9vY3NwLnh1ZGEwNQYIKwYBBQUHMAKGKWh0dHA6Ly93d3cuZS1ndXZl
bi5jb20vZG9jdW1lbnRzL0tPSzIuY3J0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
Af8EBTADAQH/MIIBJQYDVR0gBIIBHDCCARgwggEUBglghhgDAAEBAgEwggEFMDYG
CCsGAQUFBwIBFipodHRwOi8vd3d3LmUtZ3V2ZW4uY29tL2RvY3VtZW50cy9ORVNV
RS5wZGYwgcoGCCsGAQUFBwICMIG9HoG6AEIAdQAgAHMAZQByAHQAaQBmAGkAawBh
ACAAaQBsAGUAIABpAGwAZwBpAGwAaQAgAHMAZQByAHQAaQBmAGkAawBhACAAdQB5
AGcAdQBsAGEAbQBhACAAZQBzAGEAcwBsAGEAcgExAG4BMQAgAG8AawB1AG0AYQBr
ACAAaQDnAGkAbgAgAGIAZQBsAGkAcgB0AGkAbABlAG4AIABkAG8AawD8AG0AYQBu
ATEAIABhAOcBMQBuATEAegAuMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9zaWwu
ZS1ndXZlbi5jb20vRWxla3Ryb25pa0JpbGdpR3V2ZW5saWdpQVNSb290L0xhdGVz
dENSTC5jcmwwHwYDVR0jBBgwFoAUn+5Es5TV+pFPLtlVmgRW2y3E26UwHQYDVR0O
BBYEFON4rWvbwLxRhx5IF35ew5u+oPfrMA0GCSqGSIb3DQEBBQUAA4IBAQANIlpG
ovl2fXjm19DersJMkSzCzelqins88kJULbQMzHAenXIAjvohS4sJRhlM7Nabvi4f
uf6FobfdZSuvE+CxwK/QvJ5FGj3SftLo27ambf6iq+SUd++9pos9wuFj+jNjoxhK
8C0fHU2/odkoZ++viU/BWAdQ0TDaGM/J+DYTV4TRJr8JVi7ygFYN0S4c/Xnw4ktK
Iw51YvUcDvFp/mntLXRB1MkH1iNna87D21JrST9oMuw5oEWPd0n4eurB+1gOQ3Fp
NHUW5YHkOdUm+psL3nxAcCaqOlSQiye5tVQPFT3+Y/5ORUgqJXIv8sDiDIm+wSE3
tdlvzBKrP1f/TbhH
-----END CERTIFICATE-----


EGUVEN SECURE CLIENT INT. ROOT

-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgIQe5gKU8ZjcFxpm0j2+Wsr3TANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJUUjEoMCYGA1UEChMfRWxla3Ryb25payBCaWxnaSBHdXZlbmxp
Z2kgQS5TLjE8MDoGA1UEAxMzZS1HdXZlbiBLb2sgRWxla3Ryb25payBTZXJ0aWZp
a2EgSGl6bWV0IFNhZ2xheWljaXNpMB4XDTA4MTExMzExNTMwNloXDTE3MDEwMzEx
MzQwN1oweDELMAkGA1UEBhMCVFIxJzAlBgNVBAoMHkVsZWt0cm9uaWsgQmlsZ2kg
R3V2ZW5saWdpIEEuUzEbMBkGA1UECwwSUHJpbWFyeSBDbGFzcyAzIENBMSMwIQYD
VQQDDBplLUd1dmVuIFByaW1hcnkgQ2xhc3MgMyBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL7pOjxkFIn03uYrAUruFHNKgQcur3nJBayqeeYtKeuf
rJCOHinodQZURAP5dWDPTEN8ELDN33Qf7cTmkP7AuOTP9yuTPlyCbVOw68QHuVgs
XuOw2SP91E2Qh69/RMiXWja6IBK9BjydgGArSsQTYyvLe3/HZ6Mu0Q+db1ODaf7y
CB0cBzBDNOnLUWRGSYSC/NTdrdOj/tsGjl3XCyddZMZCl/RJPqlr9yLsialf8bT1
RsyI8lZ/+SpuAvcEMU9BGR7+hWhcg9V7S+wrB+CuGGq3mNxlZjqqoOS7QkDJ2UUs
QFsouyoiIXuMmXgF9bbXGpGOVfBsn3SsWv/0+EuYdo0CAwEAAaOBujCBtzAPBgNV
HRMECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjBUBgNVHR8ETTBLMEmgR6BFhkNo
dHRwOi8vc2lsLmUtZ3V2ZW4uY29tL0VsZWt0cm9uaWtCaWxnaUd1dmVubGlnaUFT
Um9vdC9MYXRlc3RDUkwuY3JsMB0GA1UdDgQWBBRcwCKIl8g+BdLy8p5Hq3cmiPGD
4TAfBgNVHSMEGDAWgBSf7kSzlNX6kU8u2VWaBFbbLcTbpTANBgkqhkiG9w0BAQUF
AAOCAQEAQ+Wb6Tvh8gxwjTWhcWEvvvunMPpSichQLSJ5KjHud6ioBeyGh+CgqCrr
gB2AoEVbqBfgFzG3TjsaYmT6MNzgAXAINEgHRzezNCz2Srm2HoOjUKR4upWnD9BM
YNv7Ui/430NCUX524wfqrRsgWMeJd2/YX+SeAlxDpXFZaUnUeqZ71MddcRLjE55A
UDk44FnWeQOWuUrm285Bo9O5kXFoyQhhGegluX0j9CCkuFR+6C2NOIRYdbW5Cst2
9CGyCmohI98N08JmIcf9CVlJJl/R7V0/hTNR60Jnj3MNxBI565uXIFwF0tVol1wY
2YuZaiXzZ2gvvdXh5QgUV1YTkQlUAg==
-----END CERTIFICATE-----

Comment 1

[Alpaslan]

Attachment: Our root cert hierarchy

Comment 2

[Kathleen Wilson]

Accepting this bug.

I will begin the Information Gathering and Verification phase soon as described in
https://wiki.mozilla.org/CA:How_to_apply

In the meantime, please provide as much information as you can as listed in
https://wiki.mozilla.org/CA:Information_checklist

Thanks,
Kathleen

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Note that, per policy, Mozilla now only adds root CA certs into its products.
Of the 4 certs included in comment 0, only the first one is a root.  
The other three are intermediate CA certificates.

Comment 4

[Alpaslan]

Attachment: We filled information check list form.

There is an attachment in the file (P7B) including cert.

Comment 5

[Kathleen Wilson]

I am unable to view the information in the attachment
https://bugzilla.mozilla.org/attachment.cgi?id=364882

Can you provide the information in a pdf, word, or excel file?

Comment 6

[Alpaslan]

Attachment: Information check list word format

Comment 7

[Kathleen Wilson]

Attachment: E-Guven Root Cert

Comment 8

[Kathleen Wilson]

Thank you for the information that you have provided. Please also provide the following:

1) Links to your CP and/or CPS. Preferably both the Turkish and the English versions.

2) The sections or page numbers of the CP/CPS that describe the procedures for verifying the identity and/or organization of the cert requester. 
Are SSL certs ever issued in which only the domain name is verified, and the identity/organization is not verified?

3) The sections or page numbers of the CP/CPS that describe the measures that are taken to verify the following information for end-entity certificates chaining up to this root, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a)for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
b)for a certificate to be used for digitally signing and/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; 

4) For testing purposes, please provide a URL to a website whose certificate chains up to this root. Note that this can be a test site.

5) Please review the potentially problematic practices at http://wiki.mozilla.org/CA:Problematic_Practices. Provide further information when relevant.

6) The auditor statement that has been provided appears to be from 2007. Is there a more recent audit report? For audit requirements, please see sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

Comment 9

[Alpaslan]

You may find our answers below.

1) Links to your CP and/or CPS. Preferably both the Turkish and the English
versions.

Unfortunately we have only turkish version now. 
http://www.e-guven.com/Documents/genel_kullanima_iliskin_nes_ilkeleri.pdf

2) The sections or page numbers of the CP/CPS that describe the procedures for
verifying the identity and/or organization of the cert requester. 

Section 7 defines and explains procedures that must be completed before issuing a qualified electronic signature. 2 models are used for Qualified electronic signatures enrollment. These are explained in detail in our CP link. 

In both we use a signed agreement which should be signed after face to face identity verification. 

Are SSL certs ever issued in which only the domain name is verified, and the
identity/organization is not verified?

As a Certification Authority we are responsible for every information written in certificates. We verify every information from several resources. We verify organization names from government web services / Local Commerce Chambers providing up to date company information.

3) The sections or page numbers of the CP/CPS that describe the measures that
are taken to verify the following information for end-entity certificates
chaining up to this root, as per section 7 of
http://www.mozilla.org/projects/security/certs/policy/.

a)for a certificate to be used for SSL-enabled servers, the CA takes reasonable
measures to verify that the entity submitting the certificate signing request
has registered the domain(s) referenced in the certificate or has been
authorized by the domain registrant to act on the registrant's behalf;

For SSL certificates signed and stamped ( organization  ) agreement is represented  to us. Organization information is checked from local commerce chambers .  Who information is verified for administrative contact of domain name from ( www.internic.net/ whois/  - .com,.net.org      www.nic.tr - .com.tr, org.tr…) 


b)for a certificate to be used for digitally signing and/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; 

If email address will be published in a certificate it should be validated by sending a confirmation email to that address. 

4) For testing purposes, please provide a URL to a website whose certificate
chains up to this root. Note that this can be a test site.

https://www.e-guven.com/popup_pnbf.asp

5) Please review the potentially problematic practices at
http://wiki.mozilla.org/CA:Problematic_Practices. Provide further information
when relevant.
1.1 Long-lived DV certificates 
We issue 1-3 years of SSL certificates. and require applicant to prove his/her organization infor and domain info.
1.2 Wildcard DV SSL certificates 
1.3 Delegation of Domain / Email validation to third parties 
We do not delegated validation procedures to any other third party for email /domain validation.
1.4 Issuing end entity certificates directly from roots 
Our root certs are stored in HSM 's. We only issue SSL certs from our root.
1.5 Allowing external entities to operate unconstrained subordinate CAs 
-- 
1.6 Distributing generated private keys in PKCS#12 files 
In every key generation scenario keys are generated in client side by enrollment pages.
1.7 Certificates referencing hostnames or private IP addresses 
---
1.8 OCSP Responses signed by a certificate under a different root 
---
1.9 CRL with critical CIDP Extension 
--
1.10 Generic names for CAs 
We do not have a generic CA name 


6) The auditor statement that has been provided appears to be from 2007. Is
there a more recent audit report? For audit requirements, please see sections
8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

We are using RSA 's CA solution and you can find our latest audit report for ISO 27001 Certificate in the attached file.

Comment 10

[Alpaslan]

Attachment: Audit report for ISO 27001

Our latest audit document from Turkish Standarts Institute

Comment 11

[Kathleen Wilson]

Thank you for the information.

Please provide a version of the CPS document in which the content can be copied, so that I can copy-paste into Google Translate.

> RE: For SSL certificates signed and stamped (organization  ) agreement is represented  to us. Organization information is checked from local commerce chambers .  Who information is verified for administrative contact of domain name from ( www.internic.net/ whois/  - .com,.net.org      www.nic.tr - .com.tr, org.tr…)

In which section or page number will I find this in the CPS?

> RE: If email address will be published in a certificate it should be validated by sending a confirmation email to that address.

In which section or page number will I find this in the CPS?

> Re: Our root certs are stored in HSM 's. We only issue SSL certs from our root.

So the hierarchy is as follows (please correct if this is wrong):
This root has three subordinate-CAs, 
1) E-Guven Mobile CA : Issues mobile certificates for end users. 
2) E-Guven NES CA : Issues qualified electronic certificates for Turkish citizens.
3) E-Guven Secure Client Certificates : Used to issue Class3 certificates.
There is no subordinate-CA for issuing SSL certificates. SSL certificates are issued directly from the root.

> RE: Audit report for ISO 27001
According to sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/
We’ll need a publishable statement or letter from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for this root, and that the CA does indeed follow these practices and meets the requirements of one of:
ETSI TS 101 456
ETSI TS 102 042
WebTrust Principles and Criteria for Certification Authorities

The audit criteria needs to clearly include one or more of these audit criteria, and the audit statement needs to confirm that.

Comment 12

[Alpaslan]

Attachment: Compliance for ETSI TS 101 456

You may find our ETSI TS 101 456 compliance document in the attached file and URL below.

http://www.tk.gov.tr/eimza/doc/aciklama/eguven.jpg

Comment 13

[Kathleen Wilson]

This statement of compliance with ETSI 101.456 appears to be from 2007. The expectation is that roots included in Mozilla are audited annually as per the audit criteria listed above. Has this root been audited more recently?

Also, in addition to my questions in Comment #11, please provide translations into English of the sections of the CP/CPS documents pertaining to:
+ Verification of Identity and Organization
+ Verification of ownership/control of domain name
+ Verification of ownership/control of email address
+ Section 7 of http://www.mozilla.org/projects/security/certs/policy/
+ Potentially Problematic Practices, http://wiki.mozilla.org/CA:Problematic_Practices

Comment 14

[Alpaslan]

I am working on items you wanted.  As soon as my work is finished, I will share them with you .

Comment 15

[Alpaslan]

Sorry for late response,
We have worked on items that you have required. 
You can find them below.

+ Verification of Identity and Organization
E-Güven  may use Dun & Bradstreet (D&B) or TOBB database  to check company registration.
The name appearing in the distinguished name in the certificate application must match the name on file with D&B or TOBB database with the exception of the organization’s extension (for example: Inc., Co, Ltd, N.V., B.V., etc.).  We do not require the customer to include their company's extension.  For instance, if a customer enrolled as XYZ and the name on the D&B or TOBB database report is XYZ A.S. , this would be accepted since the ‘A.S. can be dropped.  If the name does not match or the organization does not have a D&B number or TOBB database, notify the customer to correct the incorrect information or submit an alternative proof of right document (criteria for alternative proof of right documents will be covered in your training class and later on in this document). 



+ Verification of ownership/control of domain name
Verify that the organization requesting the ID also owns the domain name that appears in the common name field in the distinguished name as with the validation of the organization name, we do not require the customer to include their company's extension for example: Ltd, AS,  etc. For instance, if the organization name in the Distinguished Name is XYZ and the domain registrant is XYZ Ltd.  Since the ‘Ltd’ can be dropped, the domain can be approved.   
The common name cannot be an IP address or include spaces, commas, slashes or other similar characters. 
We find the appropriate domain registry for the domain in the request.  To check a .com, .net, or .org domain, go to Checkdomain’s whois http://www.name.com.. Or , go to https://www.nic.tr  or an ICANN-Accredited registrar

+ Verification of ownership/control of email address

E-Guven makes confirmation of the applicant’s e-mail address by requiring the applicant to be able to answer an e-mail to relevant address.

+ Section 7 of http://www.mozilla.org/projects/security/certs/policy/
Explained above.

+ Potentially Problematic Practices,
Already given these answers in Comment #9:5
http://wiki.mozilla.org/CA:Problematic_Practices

Comment 16

[Kathleen Wilson]

Thank you for the explanation of the verification procedures.  However, as per Mozilla policy I need to be able to find the information in a publicly available and audited document, such as the CP/CPS.

The link that I have for the CP/CPS is:
http://www.e-guven.com/Documents/genel_kullanima_iliskin_nes_ilkeleri.pdf

The problem I am running into is that this document is locked so that I cannot copy from the document.  This means that I cannot copy-and-paste into a translator to confirm that the description of the verification procedures is therein.

Could you please change the security preferences on that document to allow me to copy the text, so that I can run it through translation into English?

Comment 17

[Alpaslan]

Attachment: Our relevant CP/CPS documents .

Our relevant CP/CPS documents .

Comment 18

[Alpaslan]

Attachment: other CP/CPS documents

other CP/CPS documents

Comment 19

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and verified for this request. Within the document the items highlighted in yellow indicate where further clarification is needed.

Comment 20

[Alpaslan]

Attachment: answers for your last questions.

our comments are highlighted with green

Comment 21

[Alpaslan]

Attachment: missing document

all missing information is in this file for SSL and security certificates. sorry for confusion.

Comment 22

[Kathleen Wilson]

Thanks for the information. 

> Attached documents

Thanks for attaching the documents with copy-and-paste enabled. This allowed me to use Google Translate.

For all of the documents, I will also need to have a link to the document as it is posted on your website.
Please provide the direct url on your website to each of the following documents: 
SUE_1 0_v2.doc
MKNESI_1.1_02_08_2007_temiz.doc
NESUE_2.1_03_08_2007_temiz.doc

>> When will a more recent ETSI 101 456 audit be available?
> We will be audited next year due to auditor organizations schedule

What part of next year (eg approximately which months) do you expect the audit to happen? 

When the audit is completed, please have the auditor provide a new statement of ETSI 101 456 compliance, and have the auditor’s statement include information about it covering the issuance of SSL and Email certificates according to the documents that you provided (SUE, MKNESI, NESUE).

> Certificate Summary

Please confirm, correct, or make the following statement more clear:

The “e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi” root certificate signs SSL certificates directly. Additionally, this root has the following three intermediate CAs: E-Guven Mobile CA issues mobile certificates for end users; E-Guven NES CA issues qualified electronic certificates for Turkish citizens; and E-Guven Secure Client Certificates issues Class 3 certificates (What are Class 3 certificates?). All of the intermediate CAs chaining up to this root are operated internally by e-Guven.

Comment 23

[Alpaslan]

Here is our comments to your questions ;

1)  Exact URL's for pdf versions of relevant documents are 
http://www.e-guven.com/Documents/MKNESI_1.1.pdf
http://www.e-guven.com/Documents/NESUE_2.1.pdf
http://www.e-guven.com/Documents/SUE_1.0.pdf

2) We are expecting it on March of 2010.

3) I confirm that CA structure that you have mentioned is correct.

Comment 24

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 25

[Kathleen Wilson]

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

Note that approval will be contingent on the next audit that meets the requirements of sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/. This root is audited yearly for ISO:27001 criteria. The next ETSI 101 456 audit is planned for March, 2010.

All of the other information has been verified, so I would like to move forward with the discussion phase, noting that the new ETSI audit will be needed before approval.

Comment 26

[Alpaslan]

Attachment: Updated compliance document for ETSI TS 101 456

Compliance document from Information and Communication Technologies Authority dated 31.12.2009

Comment 27

[Kathleen Wilson]

Thank you for posting the new audit statement.  As per Mozilla process I have independently contacted the ICTA and have confirmed the authenticity of the attached audit statement.

Comment 28

[Alpaslan]

During last 6 months , significant electronic signature projects were started in Turkey government side. Because of not having our root cert included in Firefox browsers we have lots of end user complaints in our call center. 

Could you please increase priority of this case ?

Comment 29

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the information gathering document in preparation for the upcoming
public discussion.

I'll post an update here in this bug when I start the discussion in a few weeks, as per https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 30

[David E. Ross]

To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  This request is already in that queue.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process (e.g., skipping the public discussion) can only weaken the trust users have in the overall certificate database.

Those who are anxious for this root certificate -- those who already trust it and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificate themselves.  The link is at <http://www.mozilla.org/projects/security/certs/pending/#E-Guven>.  

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there.  

Note well:  These are my personal comments.  I do not work for either the Mozilla Foundation or the Mozilla Corporation.  Thus, these comments do not reflect the position of either organization.

Comment 31

[Kathleen Wilson]

I am now opening the first public discussion period for this request from E-Guven to add the “e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi” root certificate.

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 “E-Guven Root Inclusion Request”

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

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

Comment 32

[Alpaslan]

You may find our comments below.

On 24 Nisan, 00:43, Eddy Nigg <[e-mail]> wrote:
> On 04/24/2010 12:05 AM, Kathleen Wilson:
>
> > E-Guven (a private corporation that serves certificates mainly to 
> > the Turkish market) has applied to add the “E-Guven Kok Elektronik 
> > Sertifika Hizmet Saglayicisi” root certificate, and to enable the 
> > websites and email trust bits.
>
> Thanks Kathleen, hereby some of the (routine, almost obligatory) questions:
>
> > * This root certificate signs SSL certificates directly. 
> > Additionally, this root has the following three internally-operated 
> > intermediate
> > CAs: E-Guven Mobile CA issues mobile certificates for end users; 
> > E-Guven NES CA issues qualified electronic certificates for Turkish 
> > citizens; and E-Guven Secure Client Certificates issues Class 3 
> > certificates.
>
> Considering that E-Guven already deploys intermediate CA certificates, 
> I don't see any benefit for issuing other certificates directly from 
> the CA root. What exactly were the considerations for that and 
> pressing reasons for such an implementation?

E-Guven : We decided this CA hierarchy after facing some problems from our customers. Although this is not a mandatory issue , we are planning to have new intermediate root for SSL certificates by 2012.
>
> > ** The procedures for verifying the identity of the certificate 
> > subscriber are in the NESUE document in section 3.2.3. Here is a 
> > summary from the CA in regards to verifying the organization: 
> > E-Güven may use Dun & Bradstreet (D&B) or TOBB database to check 
> > company registration. The name appearing in the distinguished name 
> > in the certificate application must match the name on file with D&B 
> > or TOBB database with the exception of the organization’s extension 
> > (for
> > example: Inc., Co, Ltd, N.V., B.V., etc.).  … If the name does not 
> > match or the organization does not have a D&B number or TOBB 
> > database, notify the customer to correct the incorrect information 
> > or submit an alternative proof of right document.
>
> I'd like to receive more information on that, in particular what are 
> the verification steps E-Guven performs beyond making sure the name 
> matches in the relevant third party registries. For example if I'd 
> request a certificate for Verisign, Inc. and the entry matches that of 
> D&B will I get a certificate in their name?
>
>
E-Guven : We request a signed agreement from our customer and documents proving applicants authority to represent the company.
So checking D&B record or TOBB record is not for us.  We know it is a hard procedure but we do it like this.

>
> > ** The procedures for verifying the ownership/control of the domain 
> > name to be included in the certificate is in the SUE document. Here 
> > is a summary from the CA: Verify that the organization requesting 
> > the ID also owns the domain name that appears in the common name 
> > field in the distinguished name as with the validation of the organization name.
> > The common name cannot be an IP address or include spaces, commas, 
> > slashes or other similar characters. We find the appropriate domain 
> > registry for the domain in the request.  To check a .com, .net, or 
> > .org domain, go to Checkdomain’s whoishttp://www.name.com.
>
> Is the site name.com and authoritative source for WHOIS lookups? Did 
> E-Guven receive any guaranties from this web site operator that the 
> responses provided are correct? What is E-Guven's relation to this operator?

E-Guven :http://www.icann.org/en/registrars/accredited-list.html
name.com is listed in accredited registrars.
We will be updating our records by icann's whois resources.

>
> > *** Google Translation from Appendix C of the SUE document: E-Guven 
> > will verify the information and official documents as follows. … 
> > Domain Name:www.name.comor .com.tr extension for domain names 
> > registered whois servers aswww.nic.trcan be controlled.
>
> Which official documents? This isn't clear to me, please explain...

E-Guven : Official documents are used to prove authority of applicant to move on behalf of (represent )company.


>
> > ** Google Translation from Section 3.2.2 of SUE: SSL certificate to 
> > be granted to legal entities in the commercial register recording 
> > the identity of certificate applicants, the signature is verified 
> > through official documents such as sürküleri. As well as knowledge 
> > of electronic mail sent from the user to control up to e-mail with 
> > the correct response is to be taken.
>
> Also here, I'd like to receive a more detailed explanation what 
> exactly E-Guven does. How and which signatures are verified? What kind 
> of email is sent and what is a correct response?

Applicants signature on agreement is verified by signature samples (authorized by government.). Confirmation email is sent to domains contact. We request a confirmation of issuance of a SSL certificate for relevant domain.
>
> > * Audit: E-Guven has recently been audited according to the ETSI 101
> > 456 criteria by the Turkey Government's Information Technologies and 
> > Communications Authority (ICTA ,http://www.tk.gov.tr). The audit 
> > statement was attached to the bug 
> > (https://bugzilla.mozilla.org/attachment.cgi?id=421006). I exchanged 
> > email with the auditor to confirm the authenticity of the audit 
> > statement. E-Guven is also audited annually by the Turkish Standards 
> > Institute according to the ISO:27001 criteria.
>
> Kathleen, which email address did you use for confirmation? The one 
> stated in the audit report? Did you in any way verify the authority of 
> the signer and/or used email address?
>
> --
> Regards
>
> Signer:  Eddy Nigg, StartCom Ltd.
> XMPP:    [e-mail]
> Blog:    http://blog.startcom.org/
> Twitter:http://twitter.com/eddy_nigg

Comment 33

[Alpaslan]

Attachment: updated validation plan file.

Our updated validation document can be found in attached file.

Comment 34

[Alpaslan]

Attachment: updated CPS

Our updated CPS documents can be found in attached file.  ( Item 4.5.2 - Intermediate CA  planning.)

Comment 35

[Alpaslan]

We have updated our documents and published in our web site in the following links.

http://www.e-guven.com/documents/SUE_v1.2.pdf

http://www.e-guven.com/default.asp?ID=52

Sections 3.2.2 and 4.5.2 are updated for verification steps and intermediate CA issuance.

Comment 36

[Kathleen Wilson]

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 the request to add the “E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi” root certificate, and to enable the websites and email trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by E-Guven, 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-Guven appears to provide a service relevant to Mozilla users: It is a private corporation that serves certificates mainly to the Turkish market.

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 SSL Certificate Applications Basics (SUE), and the CP and Certificate Application Basics for Qualified Electronic Certificates. The documents are in Turkish. English translations were provided for certain sections of the documents.

** SSL Certificate Application Basics (SUE) 
http://www.e-guven.com/documents/SUE_v1.2.pdf
English: https://bugzilla.mozilla.org/attachment.cgi?id=447094

** E-Guven Qualified Electronic Certificate Policy (GKNESI) 
http://www.e-guven.com/Documents/genel_kullanima_iliskin_nes_ilkeleri.pdf 

** E-Guven Qualified Electronic Certificate Application Basics (NESUE) 
http://www.e-guven.com/Documents/NESUE_2.1.pdf 

Section 7 [Validation]. E-Guven appears to meet the minimum requirements for subscriber verification, as follows:

* Email: E-Guven uses an email challenge-response mechanism to confirm that the certificate subscriber owns/controls the email address to be included in the certificate.

* SSL: According to section 3.2.2 of the SUE, E-Guven verifies that the organization’s identity matches the domain registration and D&B record, or TOBB database, then E-Guven conducts a verification phone call to confirm the organization name and location, common name, technical contact email address, and corporate contact email address. Then E-Guven sends email to the corporate contact. After the corporate contact replies to the email, then E-Guven checks whois records to make sure that the organization address listed in the domain registration matches the corporate contact address or technical contact address in the whois record.

* Code: Not Applicable. E-Guven is not requesting that the Code Signing trust bit be enabled at this time. 

Section 8-10 [Audit]. Section 8-10 [Audit]. 
* E-Guven has recently been audited according to the ETSI 101 456 criteria by the Turkey Government's Information Technologies and Communications Authority (ICTA , http://www.tk.gov.tr). The audit statement was attached to the bug (https://bugzilla.mozilla.org/attachment.cgi?id=421006). I exchanged email with the auditor to confirm the authenticity of the audit statement. E-Guven is also audited annually by the Turkish Standards Institute according to the ISO:27001 criteria.

Section 13 [Certificate Hierarchy]. 
* This root certificate currently signs SSL certificates directly. However, as per section 4.5.2 of the SUE, E-Guven plans to introduce an intermediate root certificate for signing SSL certificates.
* Additionally, this root has the following three internally-operated intermediate CAs: E-Guven Mobile CA issues mobile certificates for end users; E-Guven NES CA issues qualified electronic certificates for Turkish citizens; and E-Guven Secure Client Certificates issues Class 3 certificates. 
** CA hierarchy diagram: https://bug476428.bugzilla.mozilla.org/attachment.cgi?id=360065

Other: 
* NextUpdate for the CRLs for end-entity certs is 24 hours.
* OCSP is provided.

Based on this assessment I intend to approve this request to add the “E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi” root certificate, and to enable the websites and email trust bits.

Comment 37

[Kathleen Wilson]

To the representatives of E-Guven: 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 #36, and on behalf of the Mozilla project I
approve this request from E-Guven to include the following root certificate in
Mozilla, with trust bits set as indicated:

* E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi(web sites, email)

I will file the NSS bug to effect the approved changes.

Comment 38

[Kathleen Wilson]

I have filed bug 571932 against NSS for the actual changes.

Comment 39

[Kathleen Wilson]

I have confirmed that the following root cert is a Builtin Object Token in
Firefox 3.6.12.

CN = E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
SHA1 Fingerprint: dd:e1:d2:a9:01:80:2e:1d:87:5e:84:b3:80:7e:4b:b1:fd:99:41:34

Comment 40

[Kathleen Wilson]

Attachment: E-Guven-auditStatment-2014.PDF

Comment 41

[Kathleen Wilson]

E-Guven is also listed here: http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/eshs.php

However, I see the following problems with the attached audit statement:

1) It says: "The last supervision of E-Guven was held by ICTA between 21st and 25th of October, 2013."
Mozilla policy requires an annual audit, so this doesn't meet Mozilla's requirement.

2) The criteria listed are: "ETSI TS 101 456" and "ETSI TS 102 023".
The websites trust bit is enabled for this root, so Mozilla requires an audit according to one of the following criteria:
 -- ETSI TS 102 042 V2.3.1 or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies);
OR
-- WebTrust "Principles and Criteria for Certification Authorities 2.0" or later and "SSL Baseline Requirements Audit Criteria V1.1" (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities;

REFERENCE: https://wiki.mozilla.org/CA:BaselineRequirements#ETSI_BR_Audit_Statement.2FCertificate