Closed Bug 877744 Opened 11 years ago Closed 10 years ago

Adding E-Tuğra EBG new root certificate in Mozilla and enable it for EV

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dtokgoz, Assigned: kwilson)

References

Details

(Whiteboard: EV - Approved - in FF29, EV treatment in FF30)

Attachments

(9 files, 1 obsolete file)

Attached file etugra_root.crt
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

The existing root certificate of E-Tugra that had already been included to the trusted CA list on the Mozilla store, will be expired on August, 2016 which means expires on in 3 years. And according the laws of of Turkey which revised about 5 mounts ago, we have to issue new certificates with at least sha256 algoritm and with 2048 bits after July, 2013. For these reasons, we have already produced a new root certificate and declared its hierarchy. The certificate was produced under the observation of Qualified Auditor witness according to requirements of  “Key Generation Ceremony” of “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”  and “Guidelines for Issuance and Management of Extended Validation Certificates” published at http://www.cabforum.org by “CA/Browser Forum”. The observation letter of the E-Tugra key ceremony by of Qualified Auditor witness is attached. We want to add this new root to Mozilla store as a second hierarchy as well. 
Notice that, the bug number of inclusion of  the existing root certificate of E-Tugra on the Mozilla is 443653 (it can be viewed on http://www.mozilla.org/projects/security/certs/included/#E-TUGRA). 

The new root certificate is attached.
Certificate Name is “E-Tugra Certification Authority”
Sha1 Fingerprint is : 51c6e70849066ef392d45ca00d6da3628fc35239
Sha2 fingerprint is : b0bfd52bb0d7d9bd92bf5d4dc13da255c02c542f378365ea893911f55e55f23c

We update and arrange our CP and CPS by including new root and EV SSL requirements with “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”  and “Guidelines for Issuance and Management of Extended Validation Certificates” published at http://www.cabforum.org by “CA/Browser Forum”. Their English and Turkish versions of them are also attached and they are published on www.e-tugra.com.tr/cps. 

E-Tugra was also completed auditing process by the BIS for the EV SSL issuance according to ETSI 102 042. New CP and CPS covers EV SSL certificates and its policies with respect to guideless on cabforum.





Expected results:

•	The new root certificate should be included to Mozilla Root CA Store as previous root.
•	Enable new E-Tugra root certificate for EV.
I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: EV
The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
Whiteboard: EV → EV - Information incomplete
The highlighted items on last document was fixed as follows:

Test Website URL: 
The demo web address are working well. The reason of problem was from DNS settings and fixed.
https://sslev.e-tugra.com.tr
https://sslov.e-tugra.com.tr 
https://ssldv.e-tugra.com.tr

OCSP URL: 
For the answer of the your question “What is the maximum expiration time that is set in the OCSP response?” is:
Since we are always sending the current status in the OCSP response (never cached) we are not providing an expiration time in the response (no nextUpdate). 

EV Policy OID(s):
The test was completed and the screenshot and the test_ev_roots.txt file are attached to the bug.

Audits:
The current audit will be available in the earlier of August. The auditing was completed and reported us completed. We are waiting BSI to define it on their system. When available we upload it ASAP.

DNS names go in SAN:
Your comment is right and it was written as accidentally. It was fixed and replaced on web site.

OCSP Responses signed by a certificate under a different root:
EV test screenshot will also show the test of the this item.
Attached image EV Test Screenshot
Contact information is corrected.
Attachment #783794 - Attachment is obsolete: true
The latest audit statement from BSI by 29 July 2013
I'll try to start the discussion soon.
Whiteboard: EV - Information incomplete → EV - Information confirmed complete
I am now opening the first public discussion period for 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.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

The discussion thread is called “E-Tugra Request to Include Renewed Root”.

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

A representative of E-Tugra must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Information confirmed complete → EV - In public discussion
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “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.

Section 4 [Technical]. I am not aware of instances where E-Tugra has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Section 6 [Relevance and Policy]. E-Tugra appears to provide a service relevant to Mozilla users. It 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.

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 CPS and CP, which have been translated into English.

Document Repository: http://www.e-tugra.com.tr/CPS
CP: http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SI_v3.1_0_EN.pdf
CPS: http://www.e-tugra.com.tr/Portals/3/engdoc/E-Tugra_SUE_v3.1_0_EN.pdf

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

* SSL: From section 3.2.5 of the CPS: 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.

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

* Code: According to section 3.2.2 of the CPS, E-Tugra verifies the identity of the certificate subscriber and the authority of the certificate subscriber to request the certificate on behalf of the organization.

Section 18 [Certificate 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  

* EV Policy OID: 2.16.792.3.0.4.1.1.4

* 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.

Sections 11-14 [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 

Based on this assessment I intend to approve this request to add the “E-Tugra Certification Authority” root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment.
Whiteboard: EV - In public discussion → EV - Pending Approval
As per the summary in Comment #13, and on behalf of Mozilla I approve this request from E-Tugra to include the following root certificate:

** “E-Tugra Certification Authority” (websites, code signing), enable EV.

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM
Depends on: 915935
Depends on: 915946
I have filed bug #915935 against NSS and bug #915946 against PSM for the actual changes.
Whiteboard: EV - Approved - awaiting NSS and PSM → EV - Approved - in FF29, pending PSM
Hi, 
We understood that EV bit is set on on release 29 fro our root.  Do we understand right? We could not see that on release 29.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - in FF29, pending PSM → EV - Approved - in FF29, EV treatment in FF30
(In reply to Davut Tokgöz from comment #16)
> Hi, 
> We understood that EV bit is set on on release 29 fro our root.  Do we
> understand right? We could not see that on release 29.

Bug #915935 was for the inclusion of the root, and the code change for that is in release 29.

Bug #915946 is for enabling EV treatment for the root, and the code change for that is currently in mozilla30 (planned to release in June).
Attached file 2016-ETUGRA-audit.pdf
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: