E-Tugra Request to Include Renewed Root

[Kathleen Wilson]

E-Tugra has applied to include the “E-Tugra Certification Authority”
root certificate, turn on the Websites and Code Signing trust bits, and
enable EV treatment. This SHA-256 root will eventually replace the “EBG
Elektronik Sertifika Hizmet Sağlayıcısı” root that was included via
Bugzilla Bug #443653.

E-Tugra is a privately owned, commercial CA operating in Ankara, Turkey,
with customers from all geographic areas within Turkey. E-TUGRA has been
certified as one of the four authorized CAs that issues qualified
certificates as well as SSL and code signing of certificates to public
in Turkey.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=877744

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#E-Tugra

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=784704

Noteworthy points:

* The primary documents are as follows:
Document Repository: http://www.e-tugra.com.tr/CPS
CPS (English):
http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SUE_v3.0_8_EN.pdf
CP (English):
http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SI_v3.0_8_EN.pdf

* CA Hierarchy: This root will be used to issue internally-operated
SubCAs. The subCA certs may be downloaded from http://www.e-tugra.com/crt/
- “E-Tuğra Nitelikli Elektronik Sertifika Hizmet Sağlayıcısı v2” --
Issues Qualified Certificates
- “E-Tugra Domain Validated CA” -- Issues DV SSL Certificates
- “E-Tugra Organization Validated CA” -- Issues OV SSL
- “E-Tugra Organization Validated CA” -- Issues EV SSL Certificates

* The request is to turn on the Websites and Code Signing trust bits,
and enable EV treatment.

** CPS Section 3.2.2 Authentication of Organization Identity
Premium SSL and CSC (CSC = Code Signing Certificate)
The name and the title of the legal entity are verified on the basis of
official documents of the country of residence of the applicant
according to e-tuğra procedures. The e-mail address submitted by the
authorized person who conducts the application process on behalf of the
certificate owner should be verified by the authorized person. This
verification process is done by sending a distinguished user name and
activation code to the e-mail address of the authorized person.
EV SSL and EV CSC
In verification of EV SSL applications at least the following conditions
should be met:
- The name or the title, legal existence and physical existence of the
legal entity which will take place in the certificate are verified
according to the official documents of the country of residence of the
applicant. In addition to this verification, circular of signature or
another valid official document in applicable legislation is required in
order to show that certificate applicant is authorized to represent the
legal entity and to sign.
- The operational continuity of the certificate applicant is confirmed
by a current official document presented by a public institution or by a
legally authorized person to settle the official document.
- The address of the central office of the legal entity of the
certificate applicant is verified according to the legal documents of
the country of residence. Moreover, telephone numbers, submitted by the
certificate applicant in application forms are cross-checked by legal
records. The applicant is called from the verified telephone number in
order to confirm the application.
- The e-mail address submitted by the authorized person who conducts the
application process on behalf of the certificate applicant should be
verified. This verification is achieved by sending a verification e-mail
message to the authorized person.
- The domain name which will take place in the certificate should belong
to the legal entity or the right and authority to use the domain name
should be given to the legal entity by the domain name’s registered owner.
- All of the conditions to be met in the verification of the identity of
the legal entity in EV SSL certificate applications and the verification
process are conducted according to the “Guidelines for Issuance and
Management of Extended Validation Certificates” published by “CA/Browser
Forum”.

** CPS Section 3.2.5: For Standard SSL, the verification of domain name
authority is made by a successful confirmation answer received from the
contact information of the person in WHOIS records or from addresses
webmaster@<domain_name>, postmaster@<domain_name>, admin@<domain_name>,
administrator@<domain_name>, hostmaster@<domain_name>.
For Premium SSL, there is a need for an official document to support
that the applicant has the authority to act on behalf of the legal entity.
For EV SSL, procedures prepared according to the “Guidelines for
Issuance and Management of Extended Validation Certificates” published
by “CA/Browser Forum” are applied.

** CPS Section 4.1.2: The applications of Standard SSL, Premium SSL and
EV SSL are all done via e-tuğra’s web site. The generation of public and
private key is done by the applicant. During the application the
applicant uploads the CSR necessary for the certificate generation to
the system. After the completion of the application, a private code is
sent to the e-mail address of manager or technical department which
takes place in DNS records in order to verify the Domain Name.
For Premium SSL and EV SSL, documents published on e-tuğra’s web site
are delivered or sent to one of e-tuğra’s RAs together with the
documents showing the authority of the application officials authorized
by the application owner. The application process is ended by inspection
and verification of documents according to e-tuğra procedures.

** CPS Section 4.1.2: The application for “CSC” is done via e-tuğra’s
website. The generation of public and private key is done by the
applicant. During the application the applicant installs the CSR
necessary for the certificate generation to the system. After the
completion of the application, a private code is sent to the e-mail
address provided at the time of application approval.
Documents published on e-tuğra’s website are delivered or sent to one of
e-tuğra’s RAs. The application process is ended by inspection and
verification of documents according to e-tuğra procedures.


* EV Policy OID: 2.16.792.3.0.4.1.1.4

* Root Cert URL: http://www.e-tugra.com.tr/crt/Etugra_Root.crt

* Test Website:
https://sslev.e-tugra.com.tr
https://sslov.e-tugra.com.tr
https://ssldv.e-tugra.com.tr

* CRL
http://crl.e-tugra.com/etugra_root.crl
http://crl.e-tugra.com/etugra_ssldv.crl (NextUpdate: 24 hours)
http://crl.e-tugra.com/etugra_sslov.crl (NextUpdate: 24 hours)
http://crl.e-tugra.com/etugra_sslev.crl (NextUpdate: 24 hours)
CPS 2.3: CRLs for subCAs are published every 6 (six) hours, 4 (four)
times a day and with a validity time of 24 (twenty four) hours.

* OCSP
http://ocsp.e-tugra.com/status/ocsp
The OCSP response is never cached, no nextUpdate.

* Audit: Annual audits are performed BSI Group The Netherlands B.V.,
according to the ETSI TS 102 042 2.4.1 - SSL NCP-PTC-BR & EV-CP criteria.
Auditor Website:
https://pgplus.bsigroup.com/CertificateValidation/CertificateValidator.aspx?CertificateNumber=ETS+025&ReIssueDate=29%2f07%2f2013&Template=cemea_en

Audit Report: https://bugzilla.mozilla.org/attachment.cgi?id=784393

* Potentially Problematic Practices – none noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from E-Tugra to include the
“E-Tugra Certification Authority” root certificate, turn on the Websites
and Code Signing trust bits, and enable EV treatment. At the conclusion
of this discussion I will provide a summary of issues noted and action
items. If there are outstanding issues, then an additional discussion
may be needed as follow-up. If there are no outstanding issues, then I
will recommend approval of this request in the bug.

Kathleen

[Erwann Abalea]

Le mardi 6 août 2013 20:42:30 UTC+2, Kathleen Wilson a écrit :
> E-Tugra has applied to include the “E-Tugra Certification Authority”
> root certificate, turn on the Websites and Code Signing trust bits, and
> enable EV treatment. This SHA-256 root will eventually replace the “EBG
> Elektronik Sertifika Hizmet Sağlayıcısı” root that was included via
> Bugzilla Bug #443653.

[...]

> * EV Policy OID: 2.16.792.3.0.4.1.1.4

From your CP:
“e-tuğra” EV SSL Certificate Policy
It covers EV SSL certificates for servers.
Object Identifier: 2.16.792.3.0.4.1.1.4

“e-tuğra” EV Code Signing Certificate Policy
It covers the EV certificates for code signing operations.
Object Identifier: 2.16.792.3.0.4.1.1.4

The same policyIdentifier is used for both certificate types, is that correct?


Same question for the following 2 policyIdentifiers:

“e-tuğra” Premium SSL Certificate Policy
It covers SSL certificates for servers.
Object Identifier: 2.16.792.3.0.4.1.1.3

“e-tuğra” Code Signing Certificate Policy
It covers the certificates for code signing operations.
Object Identifier: 2.16.792.3.0.4.1.1.3

> * Root Cert URL: http://www.e-tugra.com.tr/crt/Etugra_Root.crt
>
> * Test Website:
> https://sslev.e-tugra.com.tr

The certificate lacks the mandatory jurisdictionOfIncorporationCountryName field.
The URL used in AIA:cAIssuer returns an HTTP 404 error.
Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).

> https://sslov.e-tugra.com.tr

The URL used in AIA:cAIssuer returns a correct object with an incorrect MIME type (application/keychain_access).
Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).

> https://ssldv.e-tugra.com.tr

The URL used in AIA:cAIssuer returns an HTTP 404 error.
Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).


The URL used in AIA:cAIssuer of your intermediate CA certificates returns an HTTP 404 error.
The same MIME type differences are found for your root CRLs.


> * OCSP
> http://ocsp.e-tugra.com/status/ocsp

Designated OCSP responder certificate doesn't contain the mandatory OCSPNoCheck extension.
The OCSP service returns an HTTP 400 error for a properly URL-encoded GET request when the Base64 representation of this request contains the character '/' (URL-encoded into '%2F').
The OCSP response contains the whole certificate chain, root included (it's not an error, but it's not necessary, since the client already has them all).

[dto...@gmail.com]

Hi,

The comments for items that you mention are below. All the items are fixed.

OID: 2.16.792.3.0.4.1.1.4
From your CP:
“e-tuğra” EV SSL Certificate Policy
It covers EV SSL certificates for servers.
Object Identifier: 2.16.792.3.0.4.1.1.4

“e-tuğra” EV Code Signing Certificate Policy
It covers the EV certificates for code signing operations.
Object Identifier: 2.16.792.3.0.4.1.1.4

The same policyIdentifier is used for both certificate types, is that correct?

[ETUGRA] Yes, that is true. The identification and Authentication procedures and policies are exactly the same for both certificate type. The only difference, the domain name ownership verification on SSL.

Same question for the following 2 policyIdentifiers:

“e-tuğra” Premium SSL Certificate Policy
It covers SSL certificates for servers.
Object Identifier: 2.16.792.3.0.4.1.1.3

“e-tuğra” Code Signing Certificate Policy
It covers the certificates for code signing operations.
Object Identifier: 2.16.792.3.0.4.1.1.3

[ETUGRA] Yes, that is true because of same reason above.

> * Root Cert URL: http://www.e-tugra.com.tr/crt/Etugra_Root.crt
>
> * Test Website:
> https://sslev.e-tugra.com.tr
The certificate lacks the mandatory jurisdictionOfIncorporationCountryName field.

[ETUGRA]: Fixed; jurisdictionOfIncorporationCountryName was configured in Certificate Management System as mandatory field. Renewed certificate was loaded to https://sslev.e-tugra.com.tr

The URL used in AIA:cAIssuer returns an HTTP 404 error.

[ETUGRA]: Fixed

Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).

[ETUGRA]: The second URL is placed on a different location for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

> https://sslov.e-tugra.com.tr

The URL used in AIA:cAIssuer returns a correct object with an incorrect MIME type (application/keychain_access).

[ETUGRA]: Fixed; Mime type is set as “application/x-x509-ca-cert”

Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).

[ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

> https://ssldv.e-tugra.com.tr

The URL used in AIA:cAIssuer returns an HTTP 404 error.

[ETUGRA]: Fixed

Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).

[ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl


The URL used in AIA:cAIssuer of your intermediate CA certificates returns an HTTP 404 error. :
[ETUGRA]: Fixed

The same MIME type differences are found for your root CRLs.

[ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

> * OCSP
> http://ocsp.e-tugra.com/status/ocsp

Designated OCSP responder certificate doesn't contain the mandatory OCSPNoCheck extension.

[ETUGRA]: Fixed, renewed OCSP certificates are loaded.

The OCSP service returns an HTTP 400 error for a properly URL-encoded GET request when the Base64 representation of this request contains the character '/' (URL-encoded into '%2F').

[ETUGRA]: Fixed

The OCSP response contains the whole certificate chain, root included (it's not an error, but it's not necessary, since the client already has them all).

[ETUGRA]: Yes that’s true, we prefer to give OSCP responses with this configuration. The qualified certificates that we issued are required this kind of OCSP responses and we prefer to setup all OCSP responses with same configuration

Davut Tokgöz

[Erwann Abalea]

Bonjour,

Le mardi 13 août 2013 22:04:52 UTC+2, Davut Tokgöz a écrit :
> Hi,
>
> The comments for items that you mention are below. All the items are fixed.


> OID: 2.16.792.3.0.4.1.1.4
> From your CP:
> “e-tuğra” EV SSL Certificate Policy
> It covers EV SSL certificates for servers.
> Object Identifier: 2.16.792.3.0.4.1.1.4
>
> “e-tuğra” EV Code Signing Certificate Policy
> It covers the EV certificates for code signing operations.
> Object Identifier: 2.16.792.3.0.4.1.1.4
>
> The same policyIdentifier is used for both certificate types, is that correct?
>
> [ETUGRA] Yes, that is true. The identification and Authentication procedures and policies are exactly the same for both certificate type. The only difference, the domain name ownership verification on SSL.

So you won't be able to have a subordinate CA technically constrained to only one of those certificate types. If a subordinate CA can produce EV-SSL certificates, it can also technically deliver EV-CodeSigning ones, defeating the CertificatePolicies purpose.

I think it's OK for Mozilla, but for you as a CA, this limits your agility. (and then browsers need to rely on non-standard constraints mechanisms such as EKU)

> Same question for the following 2 policyIdentifiers:
>
> “e-tuğra” Premium SSL Certificate Policy
> It covers SSL certificates for servers.
> Object Identifier: 2.16.792.3.0.4.1.1.3
>
> “e-tuğra” Code Signing Certificate Policy
> It covers the certificates for code signing operations.
> Object Identifier: 2.16.792.3.0.4.1.1.3
>
> [ETUGRA] Yes, that is true because of same reason above.

Same as above.

> > * Root Cert URL: http://www.e-tugra.com.tr/crt/Etugra_Root.crt
> >
> > * Test Website:
> > https://sslev.e-tugra.com.tr
> The certificate lacks the mandatory jurisdictionOfIncorporationCountryName field.
>
> [ETUGRA]: Fixed; jurisdictionOfIncorporationCountryName was configured in Certificate Management System as mandatory field. Renewed certificate was loaded to https://sslev.e-tugra.com.tr

Confirmed.

But you also added the jurisdictionOfIncorporationLocalityName, and this combination is not compliant with EV guidelines (see section 9.2.5). Based on my findings (which may not be accurate), the turkish registration agency operates at country level, so you MUST only have the jurisdictionOfIncorporationCountryName field. Nevertheless, having jurisdictionOfIncorporationLocalityName without jurisdictionOfIncorporationStateOrProvinceName isn't possible.

> The URL used in AIA:cAIssuer returns an HTTP 404 error.
> [ETUGRA]: Fixed

Confirmed.

> Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).
>
> [ETUGRA]: The second URL is placed on a different location for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

Confirmed.

> > https://sslov.e-tugra.com.tr
> The URL used in AIA:cAIssuer returns a correct object with an incorrect MIME type (application/keychain_access).
>
> [ETUGRA]: Fixed; Mime type is set as “application/x-x509-ca-cert”

Confirmed.

> Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).
>
> [ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

Confirmed.

> > https://ssldv.e-tugra.com.tr
> The URL used in AIA:cAIssuer returns an HTTP 404 error.
>
> [ETUGRA]: Fixed

Confirmed.

> Not an error, but the 2 URLs for the CRLDP extension return the same correct object with different MIME types (application/x-pkcs7-crl and application/pkix-crl).
>
> [ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

Confirmed.

> The URL used in AIA:cAIssuer of your intermediate CA certificates returns an HTTP 404 error. :
>
> [ETUGRA]: Fixed

Confirmed.

> The same MIME type differences are found for your root CRLs.
>
> [ETUGRA]: the second URL is on a different location with more simple configuration for the business continuity. Mine types on both server was adjusted as application/x-pkcs7-crl

Confirmed.

> > * OCSP
> > http://ocsp.e-tugra.com/status/ocsp
>
> Designated OCSP responder certificate doesn't contain the mandatory OCSPNoCheck extension.
> [ETUGRA]: Fixed, renewed OCSP certificates are loaded.

Confirmed. You can also remove the CRLDistributionPoints extension from these certificates, since they can't be revoked (that's the purpose of OCSPNoCheck extension), but it's not mandatory.

> The OCSP service returns an HTTP 400 error for a properly URL-encoded GET request when the Base64 representation of this request contains the character '/' (URL-encoded into '%2F').
> [ETUGRA]: Fixed

Confirmed.

> The OCSP response contains the whole certificate chain, root included (it's not an error, but it's not necessary, since the client already has them all).
>
> [ETUGRA]: Yes that’s true, we prefer to give OSCP responses with this configuration. The qualified certificates that we issued are required this kind of OCSP responses and we prefer to setup all OCSP responses with same configuration

That's a strange requirement, since the client needs the issuing certificate in order to generate a valid request, therefore it already has the issuing certificate. Having the root in the response is also strange, since no trust can be associated to a self-signed certificate inline. But these are not errors, so it's OK.

[Davut Tokgöz]

Hi, Bonjour, Merhaba

Before defining policiy identifiers, We had a long discussion internally and with experts about the using one policy identifier for SSL and Code Signing. We evaluated the disadvantage and advantages you mentioned. We could not see any opposition for this option. We thought that it is OK for browsers.

[Kathleen Wilson]

Thanks, Erwann, for reviewing this request.

Davut, I think the following still needs resolution:

>>> * Test Website:
>>> https://sslev.e-tugra.com.tr
>> The certificate lacks the mandatory jurisdictionOfIncorporationCountryName field.
>>
>> [ETUGRA]: Fixed; jurisdictionOfIncorporationCountryName
>> was configured in Certificate Management System as mandatory field.
>> Renewed certificate was loaded to https://sslev.e-tugra.com.tr
>
> Confirmed.
>
> But you also added the jurisdictionOfIncorporationLocalityName, and
> this combination is not compliant with EV guidelines (see section 9.2.5).
> Based on my findings (which may not be accurate), the turkish registration
> agency operates at country level, so you MUST only have the
> jurisdictionOfIncorporationCountryName field. Nevertheless, having
> jurisdictionOfIncorporationLocalityName without
> jurisdictionOfIncorporationStateOrProvinceName isn't possible.
>

All, are there any further comments or questions about this request from
E-Tugra to include the “E-Tugra Certification Authority” root

certificate, turn on the Websites and Code Signing trust bits, and

enable EV treatment?


Thanks,
Kathleen

[Davut Tokgöz]

27 Ağustos 2013 Salı 03:03:30 UTC+3 tarihinde Kathleen Wilson yazdı:

> Thanks, Erwann, for reviewing this request.
>
>
>
> Davut, I think the following still needs resolution:
>
> >>> * Test Website:
> >>> https://sslev.e-tugra.com.tr
> >> The certificate lacks the mandatory jurisdictionOfIncorporationCountryName field.
> >>
> >> [ETUGRA]: Fixed; jurisdictionOfIncorporationCountryName
> >> was configured in Certificate Management System as mandatory field.
> >> Renewed certificate was loaded to https://sslev.e-tugra.com.tr
> >
> > Confirmed.
> >
> > But you also added the jurisdictionOfIncorporationLocalityName, and
> > this combination is not compliant with EV guidelines (see section 9.2.5).
> > Based on my findings (which may not be accurate), the turkish registration
> > agency operates at country level, so you MUST only have the
> > jurisdictionOfIncorporationCountryName field. Nevertheless, having
> > jurisdictionOfIncorporationLocalityName without
> > jurisdictionOfIncorporationStateOrProvinceName isn't possible.
> >
>

Hi

Missing explanation for this item is my mistake.
In Turkey, Turkish registration agencies are local based and operated by chamber of commerces, with authorization rights on laws. There is a government project that aims to build centralized registration process and is completed partly called Mersis. But, it is not accepted as qualified data source by the government for now and the registration unique numbers on this registration system are not published to the public and are not used by public.
So, until the new registration system running, we should use this, and our verification procedure include this.

Regards
Davut

[Davut Tokgöz]

Hi again
I also want to note that some EV SSL providers does not take care of this for Turkey. On some EV SSLs of Turkish companies, both jurisdictionOfIncorporationLocalityName and jurisdictionOfIncorporationLocalityName is used with the same value while jurisdictionOfIncorporationLocalityName is enough.
But on some EV SSLs, there is only jurisdictionOfIncorporationCountryName. but jurisdictionOfIncorporationLocalityName must be included, because the registration number is based Istanbul registration agency.
We can give sample sites (banks) that shows both case even issued by the same SSL provider.

Davut

[Erwann Abalea]

Bonjour,

Ok. So the registration agencies operate at a locality level? If yes, based on EV Guidelines section 9.2.5, it means you MUST have all of jurisdictionOfIncorporationCountryName, jurisdictionOfIncorporationStateOrProvinceName and jurisdictionOfIncorporationLocalityName. That's the meaning of my last sentence.

If the registration agency operates at a state/province level, just use jurisdictionOfIncorporationCountryName and jurisdictionOfIncorporationStateOrProvinceName.

[Davut Tokgöz]

27 Ağustos 2013 Salı 15:20:39 UTC+3 tarihinde Erwann Abalea yazdı:
> Bonjour,

>
>
> Ok. So the registration agencies operate at a locality level? If yes, based on EV Guidelines section 9.2.5, it means you MUST have all of jurisdictionOfIncorporationCountryName, jurisdictionOfIncorporationStateOrProvinceName and jurisdictionOfIncorporationLocalityName. That's the meaning of my last sentence.
>
> If the registration agency operates at a state/province level, just use jurisdictionOfIncorporationCountryName and jurisdictionOfIncorporationStateOrProvinceName.

Hi,

You are right and we aggree your comment, We renewed the certificate at https://sslev.e-tugra.com.tr by adding jurisdictionOfIncorporationStateOrProvinceName.

Davut

[Davut Tokgöz]

Hi

We revise our CPS on section 7.1.4 for making "Subject Jurisdiction of Incorporation or Registration Field" more clear. The new version of CPS was uploaded to our repository and published as version 3.1.

The documents access info :
Document Repository: http://www.e-tugra.com.tr/CPS
CPS (English): http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SUE_v3.1_0_EN.pdf
CP (English): http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SI_v3.1_0_EN.pdf

Davut

[Kathleen Wilson]

On 8/6/13 11:42 AM, Kathleen Wilson wrote:
> E-Tugra has applied to include the “E-Tugra Certification Authority”
> root certificate, turn on the Websites and Code Signing trust bits, and
> enable EV treatment. This SHA-256 root will eventually replace the “EBG
> Elektronik Sertifika Hizmet Sağlayıcısı” root that was included via
> Bugzilla Bug #443653.
>
> E-Tugra is a privately owned, commercial CA operating in Ankara, Turkey,
> with customers from all geographic areas within Turkey. E-TUGRA has been
> certified as one of the four authorized CAs that issues qualified
> certificates as well as SSL and code signing of certificates to public
> in Turkey.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=877744
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#E-Tugra
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=784704
>

Thank you to those of you who reviewed and contributed to this
discussion about the request from E-Tugra to include the “E-Tugra

Certification Authority” root certificate, turn on the Websites and Code
Signing trust bits, and enable EV treatment.

The questions and issues that were raised during this discussion have
been resolved.

I am closing this discussion, and I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=877744

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen