448794 - Add Chunghwa Telecom eCA root certificate

Status: RESOLVED FIXED

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

Description

[Frank Hecker]

[Note: I received this request via email some time ago, and forgot to enter a bug for it; my apologies.]

CA Name: ePKI Root Certification Authority, eCA

Website: http://epki.com.tw/

One Paragraph Summary of CA, including the following:

  - General nature (e.g., commercial, government, academic/research,
    nonprofit)

  - Primary geographical area(s) served

  - Number and type of subordinate CAs

Operating in accordance with the High Assurance Level defined in the Certificate Policy(CP) of Chunghwa Telecom ecommerce Public Key Infrastructure (ePKI), ePKI Root Certification Authority (eCA) is the trust anchor of ePKI. Acting as the interface between certification authority (CA) within and without ePKI, eCA is responsible for carrying out cross-certification: issuing and managing the certificates of Level 1 subordinate CAs' within ePKI as well as the certificates of CAs from without.

The eCA is responsible for the processing of firsthand certificate applications and revocations. There is no need to set up a Registration Authority (RA) of eCA. The eCA accepts the applications from the subject CAs and authenticates them.

The eCA is a commercial CA. It is located in Taipei, Taiwan. The disaster recovery site of the eCA is located in Taichung, Taiwan. eCA has two subordinate CAs : CHTCA and Public CA. The CHTCA is the internal CA of Chunhwa telecom(CHT) which signs certificates for CHT employees. The Public CA signs certificates for CHT clients. 

Audit Type (WebTrust, ETSI etc.): WebTrust for CA

Auditor: SunRise CPAs’ Firm, a member firm of DFK international.

Auditor Website: http://www.dfk.com/

Audit Document URL(s): https://cert.webtrust.org/ViewSeal?id=695

 Certificate Details
 -------------------
 (To be completed once for each certificate)

 Certificate Name: ePKI Root Certification Authority

 Summary Paragraph, including the following:

  - End entity certificate issuance policy, i.e. what you plan to do with
    the root
 
       The eCA signs subordinate CAs only. The CPS of the eCA is available at the URL : http://epki.com.tw/download/eCA_CPS_english.pdf

   Certificate HTTP URL (on CA website): http://epki.com.tw/download/ROOTeCA.cer

 Version: X.509v3

 SHA1 Fingerprint: 67 65 0d f1 7e 8e 7e 5b 82 40 a4 f4 56 4b cf e2 3d 69 c6 f0

 MD5 Fingerprint: Not available. The eCA implements SHA1.

 Modulus Length (a.k.a. "key length"): RSA(4096 bits)

 Valid From (YYYY-MM-DD): 2004-12-20

 Valid To (YYYY-MM-DD): 2004-12-20

 CRL HTTP URL: http://epki.com.tw/repository/CRL/CA.crl

 OCSP URL: Not available. The eCA is an offline CA. Only CARL of the eCA available.

 Class (domain-validated, identity/organisationally-validated or EV):

 Certificate Policy URL: http://epki.com.tw/download/ePKI_CP_V1_chinese.pdf

 CPS URL: http://epki.com.tw/download/eCA_CPS_english.pdf

 Requested Trust Indicators (email and/or SSL and/or code): The eCA signs subordinate CAs only. The validity of the certificate is usually checked only when the end entity wants to verify the trust path. The eCA itself is the trust anchor of its sub-CAs.

Comment 1

[Frank Hecker]

Reassigning to Kathleen Wilson to do information gathering.

Comment 2

[NIEN HUA CHENG]

Certificate Details  Valid To (YYYY-MM-DD): 2034-12-20

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the Initial Information Gathering Document which summarizes the information that has been gathered and verified.  The items in the document that are highlighted in yellow indicate the information that needs to be clarified or provided. I will also summarize below.

1) There appears to be a lot of information about cross-signed CAs in the English-translated versions of the ePKI CP and the eCA CPS. Is the eCA root truly used to cross-sign CAs that are operated by third-party companies?  If so, please describe the hierarchy for cross-signed CAs. How many such cross-signed CAs are there?

2) Are there any subordinate CAs of the eCA that are operated by third parties? If so, please describe.

3) Can the PublicCA issue subordinate CAs, or only end-entity certs?

4) Please point me to the sections or text in the CP/CPS that demonstrate that reasonable measures 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; 
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

5) Please identify if all SSL certs chaining up to this root are OV, meaning that both the domain name referenced in the certificate is verified to be owned/controlled by the subscriber, and the value of the Organization attribute is verified to be that associated with the certificate subscriber.

Are there any SSL certs chaining up to this root that are only DV? Eg the Organization attribute is not verified, only the domain name is verified? (Level 1?)

6) Does eCA or PublicCA support OCSP? If so, can you provide a URL to the OCSP responder? What is the maximum time until OCSP responders are updated to reflect end-entity revocation?

7) Please provide either a website url whose cert chains up to this root, or an example cert that chains up to this root.

8) Would you please review
http://wiki.mozilla.org/CA:Problematic_Practices
and comment as to whether any of these are relevant?
 If any are relevant, please provide further information.

9) Is there a new audit report for this year, or do you have a schedule for when the 2008 audit will be performed?

Thanks,
Kathleen

Comment 4

[NIEN HUA CHENG]

Attachment: reply the informaion gathering by CHT

reply the informaion gathering by CHT

Comment 5

[Kathleen Wilson]

The information gathering/verification phase of this request is almost complete. There is only one open action item, which is to ensure that the eCA CPS meets the requirements of section 7 of the CA Policy in regards to verifying ownership of the domain name and email address. CHT is working on this.

Note that the CPS uses the term cross-certificate. From CHT:
"Within the ePKI the cross-certificate is intended to mean subordinate CA. All subordinate CAs are operated by the Data Communication Business Group, which is a division of Chunghwa Telecom."

Comment 6

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

This completes the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.

I will update the pending list to reflect this status:
http://www.mozilla.org/projects/security/certs/pending/#Chunghwa%20Telecom

I will also add this request to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule

Comment 7

[Kathleen Wilson]

For testing purposes, would you please provide the url to an https website whose certificate chains up to this eCA root?

Comment 8

[NIEN HUA CHENG]

The URL as follows:
https://epki.com.tw/index_en.htm

or

https://5th.hinet.net/higoods/index.php?action=member_login&b_action=shopping_cart

Comment 9

[Kathleen Wilson]

Thank you for the urls. That is what I needed. However, now I must ask about one more thing…

The CRL Distribution Points of the website certs of these sites are:
http://repository.publicca.hinet.net/crl/3-1/complete.crl
http://repository.publicca.hinet.net/crl/100-1/complete.crl

When I try to import either of these CRLs into Firefox, I get the following error:
The application cannot import the Certificate Revocation List (CRL).
Error Importing CRL to local Database. Error Code:ffffe095
Please ask your system administrator for assistance.

ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION
Please see: https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

Comment 10

[NIEN HUA CHENG]

Thank you for the testing. Our develop team need to change our software, we'll  release a new version next week.

Comment 11

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updating the Information Gathering Document in preparation for the public discussion phase.

Comment 12

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Chunghwa Telecom to add the ePKI Root Certification Authority root certificate to Mozilla.

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.tech.crypto newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-tech-crypto
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Chunghwa Telecom Root Inclusion Request”.

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

Comment 13

[NIEN HUA CHENG]

We had changed the CRL Distribution Points, please see:
https://epki.com.tw/index_en.htm

Comment 14

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the Information Gathering Document to include the new CRL Distribution Point URL for end-entity certs. The new CRL imports into Firefox without error.

Comment 15

[Kathleen Wilson]

To summarize, this assessment is for Chunghwa Telecom’s request to add the ePKI Root Certification Authority certificate to NSS. All three trust bits have been requested.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Chunghwa Telecom, 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]. Chunghwa Telecom appears to provide a service relevant to Mozilla users: It is a public corporation in Taiwan.

The certificate policies for Chunghwa Telecom are published on their website and listed in the entry on the pending applications list. The main documents are the ePKI Certificate Policy, eCA Certification Practice Statement, and the PublicCA Certification Practice Statement. All three are provided in English.

http://210.71.154.6/download/ePKI_CP_V1_2004.pdf
http://210.71.154.6/download/eCA_CPS_english.pdf 
http://210.71.154.6/download/PublicCA%20CPS%20English%20version1.3.pdf

Section 7 [Validation]. Chunghwa Telecom appears to meet the minimum requirements for subscriber verification, as follows:

* Email: In the eCA CPS section 3.1.8 says: “The Subject CA shall take reasonable measures to verify that the registrant controls the email account associated with the email address referenced in the certificate or has been authorized by the email address owner to act on the address owner’s behalf.” Additionally, after the authentication procedure is finished, the subscriber will receive an email from PublicCA and they must use the information of this email to finish the certificate acceptance.

* SSL: In the eCA CPS section 3.1.8 says: “The Subject CA shall take reasonable measures to verify that the registrant has registered the domain(s) referenced in the certificate or has been authorized by the domain owner to act on the owner’s behalf; For instance, the Subject CA will verify the ownership of the domain name by checking against an internal or publicly available database.” 

* Code: In the eCA CPS section 3.1.8 says: “For a certificate to be used for digitally signing code objects, the registrant shall provide its identity for verification. The Subject CA shall take reasonable measures to verify that the registrant is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity’s behalf.”

Section 8-10 [Audit]. Section 8-10 [Audit].  Chunghwa Telecom has been audited against the WebTrust CA criteria, and their audit of October, 2008, is posted on the cert.webtrust.org website. No issues were noted in the audit reports.

Section 13 [Certificate Hierarchy].  The ePKI Root Certification Authority (eCA) root has two internally-operated subordinate CAs: CHTCA and Public CA. CHTCA is the internal CA of Chunghwa Telecom (CHT) which signs certificates for CHT employees. The Public CA signs certificates for CHT clients.

Other: 
* Both CRL and OCSP are provided.
** Next update for CRLs of end-entity certs is 48 hours.

Potentially problematic practices: None Noted
* In the eCA CPS the term cross-certificate means a certificate used to establish a trust relationship between two CAs. Within the ePKI the cross-certificate is intended to mean subordinate CA. All subordinate CAs are operated by the Data Communication Business Group, which is a division of Chunghwa Telecom.

Based on this assessment I recommend that Mozilla approve the request to add the ePKI Root Certification Authority certificate to NSS, and enable all three trust bits.

Comment 16

[Frank Hecker]

To Kathleen: Thank you for your work on this request.

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

I have reviewed the summary and recommendation in comment #15, and on behalf of
the Mozilla project I approve this request from Chunghwa Telecom to include the following root certificate in Mozilla, with trust bits set as indicated:

* ePKI Root Certification Authority (SSL, email, object signing)

Kathleen, could you please do the following:

1. File the necessary bug against NSS for the root inclusion.
2. Mark this bug as dependent on the NSS bug.
3. When that bug is complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!

Comment 17

[Kathleen Wilson]

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

Comment 18

[Kathleen Wilson]

Confirmed that this root is a Builtin Object Token in Firefox 3.6.