1341604 - Add Renewed Chunghwa Telecom eCA root certificate (ePKI Root Certification Authority - G2)

Status: RESOLVED WONTFIX

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

Description

[Li-Chun CHEN]

Attachment: ePKI CP v1.3 English Version

CA Details
----------

CA Name: ePKI Root Certification Authority - G2
Website:   http://www.cht.com.tw/en/ (Company English Web Site),
           https://eca.hinet.net/ (https://epki.com.tw) (Root CA web site),
           https://publicca.hinet.net/ (Subordinate CA site),
           https://ev.hinet.net/ (Subordinate CA site,It has not yet operated)

One Paragraph Summary of CA, including the following:
    Chunghwa Telecom ecommerce Public Key Infrastructure (ePKI) was set up by Chunghwa Telecom (CHT). CHT is the largest telecommunication service provider in Taiwan and one of the largest in Asia in terms of revenue. CHT runs commerical CAs to provide certificates to the general public including natural persons, organizations, equipment, and application software.Subscribers may use certificates for e-commerce, document signing, code signing,, internet banking, internet tax filing, TLS secure connection, secure transmission, data encryption, and identity authentication, etc.

Audit Type (WebTrust, ETSI etc.): WebTrust for CA 2.0, SSL BR 2.0 and Point in Time Readiness Assessments for EV 1.4.5
Auditor: Sun Rise CPAs' FIRM DFK International
Auditor Website:http://www.sunrisecpa.com.tw/
Audit Document URL(s):https://cert.webtrust.org/SealFile?seal=2128&file=pdf, https://cert.webtrust.org/SealFile?seal=2129&file=pdf and http://eca.hinet.net/download/CHT_EV_SSL_CA_ReadinessCheckReportsAndAssertions.pdf 

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

Certificate Name:ePKI Root Certification Authority - G2
Summary Paragraph, including the following:
 
ePKI Root Certification Authority (eCA) is the highest CA (Root CA) in the hierarchical structure of ePKI (Please see the attached diagram). eCA is responsible for issuing and managing self-signed certificate, self-issued certificates and subordinate CAs'certificate within ePKI. eCA has two subordinate CAs, including Public Certification Authority and ePKI EV SSL Certification Authority.  The Public Certification Authority is responsible for signing certificates for government agencies; organizations, citizens, corporations. ePKI EV SSL Certification Authority is responsible for issuing EV SSL certificates to servers of private organization, government entity, business entities and Non-Commercial Entity (International Organizations).

eCA have these separate subordinate CAs to issue the following types of certificates:
- Extended Validation SSL Certificates
- Other types of certificates as covered by our CP and CPS (such as  OV SSL Certificates, certificate for S/MIME)
  Relying parties can check certificate policy extension of suboridinate CA certificates and EE certificates. 

Certificate download URL (on CA website):http://eca.hinet.net/download/eCA2.cer (DER encoded X.509.) and
http://eca.hinet.net/download/ eCA2_64.crt (Based 64 encoded.)

Version:X.509 v3
SHA1 Fingerprint:d9 9b 10 42 98 59 47 63 f0 b9 a9 27 b7 92 69 cb 47 dd 15 8b
Public key length (for RSA, modulus length) in bits:4096
Valid From (YYYY-MM-DD):2015-11-17‎
Valid To (YYYY-MM-DD):2037-12-31

CRL HTTP URL:http://eca.hinet.net/repository/CRL2/CA.crl
CRL issuing frequency for subordinate end-entity certificates:The CRL issuance frequency is at least twice per day. Issued CRL are valid for no more than 36 hours.
CRL issuing frequency for subordinate CA certificates:This CRL is issued at least once per day.
OCSP URL: http://ocsp.eca.hinet.net/OCSP/ocspG2sha2

Class (domain-validated, identity/organizationally-validated or EV):OV,EV,IV & DV
Certificate Policy URL: http://eca.hinet.net/download/ePKI_CP_v1.3_Eng.pdf (English Version, V1.3) and http://eca.hinet.net/download/ePKI_CP_v1.4_final.pdf (Traditional Chinese Version, V1.4)
CPS URL:http://eca.hinet.net/download/ePKI_Root_CA_CPS_v1.3_Eng.pdf  (eCA CPS English Version,V1.3). Suboridinate CA CPS as below:http://eca.hinet.net/download/PublicCA_CPS_v1.6_Eng.pdf (PublicCA CPS English Version,V1.3 ) & http://eca.hinet.net/download/ePKI_EVSSL_CA_CPS_v1.0(Eng).pdf (ePKI EV SSL CA CPS English Version,V1.0)
Requested Trust Indicators (email and/or SSL and/or code signing):email,SSL and code signing
URL of example website using certificate subordinate to this root
(if applying for SSL):https://testpublicca.hinet.net/

Comment 1

[Li-Chun CHEN]

Attachment: eCA CPS V1.3 English Version

Comment 2

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.6_Eng.pdf

PublicCA CPS Version 1.6 English Version

Comment 3

[Li-Chun CHEN]

Attachment: ePKI EVSSL CA CPS v1.0(English Version)

Comment 4

[Li-Chun CHEN]

Attachment: A diagram to show Chunghwa Telecom ecommerce Public Key Infrastructure (ePKI)

Comment 5

[Li-Chun CHEN]

ePKI Root Certification Authority was included in Mozilla NSS as https://bugzilla.mozilla.org/show_bug.cgi?id=448794

Comment 6

[Aaron Wu]

Attachment: CAInformaion_ChungHua_InfoNeeded_20170326.pdf

Comment 7

[Aaron Wu]

Hi,

We are starting the information verification of this case/root case, and please provide the information which marked "NEED CA Response" in attachment as Comment#6.

Note:
For test website, please refer to the following statement and provide valid/revoke/expired test site.
CA Browser Forum section 2.2: “The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.”

Thank you!

Kind regards,
Aaron

Comment 8

[Aaron Wu]

Hi Li-Chun,

Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Please let me know if you have any question, thank you!


Best regards,
Aaron

Comment 9

[Li-Chun CHEN]

(In reply to Aaron Wu from comment #7)
> Hi,
> 
> We are starting the information verification of this case/root case, and
> please provide the information which marked "NEED CA Response" in attachment
> as Comment#6.
> 
> Note:
> For test website, please refer to the following statement and provide
> valid/revoke/expired test site.
> CA Browser Forum section 2.2: “The CA SHALL host test Web pages that allow
> Application Software Suppliers to test their software with Subscriber
> Certificates that chain up to each publicly trusted Root Certificate. At a
> minimum, the CA SHALL host separate Web pages using Subscriber Certificates
> that are (i) valid, (ii) revoked, and (iii) expired.”
> 
> Thank you!
> 
> Kind regards,
> Aaron

Dear Aaron,

   There are some links for your testing:

    EV SSL Certificates:
    
       Valid:  https://ev.hinet.net/ 

       Expired：https://ra.testev.hinet.net

       Revoked：https://testev.hinet.net   

    OV SSL Certificates:
    Valid: https://testpublicca.hinet.net 


     Note that  ePKI EV SSL Certification Authority - G1 has accomplished Trust Service Principles and Criteria for Certification Authorities Version 2.0、WebTrust Principles and Criteria for Certification Authorities-Extended Validation SSL Version 1.4.5 & SSL Baseline with Network Security – ßVersion 2.2 (and Version 2.0) audit recently.

    The URL of seals are as below

     WebTrust (standard audit) : https://cert.webtrust.org/ViewSeal?id=2277
        
     WebTrust  EV : https://cert.webtrust.org/ViewSeal?id=2279

     WebTrust SSL BR : https://cert.webtrust.org/ViewSeal?id=2278

Sincerely Yours,

                Li-Chun Chen

Comment 10

[Aaron Wu]

Hi Mr. Chen,

Thanks for provide test websites and the link of audit statement.

1. BR Self Assessment
Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug. Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

2. Audit Case
Please create an Audit Case for your currently included root cert as per http://ccadb.org/cas/updates

Thanks,
Aaron

Comment 11

[Li-Chun CHEN]

Dear Aaron,

     1. Update links for testing:

       EV SSL Certificates:
      
          Valid:  https://ev.hinet.net/ 

          Expired：https://ra.testev.hinet.net

          Revoked：https://testev.hinet.net   

       OV SSL Certificates:

          Valid: https://testpublicca.hinet.net 
 
          Expired：https://testfca.hinet.net 

          Revoked：https://testpublicca.hinet.net

     2.   eCA and its subordinate CA (Public Certification Authority) have accomplished the annual Trust Service Principles and Criteria for Certification Authorities 2.0 audit and published the renewed Audit Report and Management's Assertions as https://cert.webtrust.org/SealFile?seal=2306&file=pdf  in accordance with WebTrust program recently. The end date of audit period is the same as that of ePKI EV SSL CA.

     eCA & its subordinate CA (Public Certification Authority) have accomplished the annual WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security Version 2.0 audit and published the renewed Audit Report and Management's Assertions as https://cert.webtrust.org/SealFile?seal=2307&file=pdf in accordance with WebTrust program recently. eCA and PublicCA will continue to maintain the validity of WebTrust Principles and Criteria for Certification Authorities – SSL Baseline Requirements seal by complying with WebTrust Principles and Criteria for Certification Authorities –SSL Baseline with Network Security. The end date of audit period is the same as that of ePKI EV SSL CA.
 
       3. I tried to create an Audit Case following the instruction of http://ccadb.org/cas/updates several hours ago.

    Thank you.

       Li-Chun Chen




(In reply to Li-Chun CHEN from comment #9)
> (In reply to Aaron Wu from comment #7)
> > Hi,
> > 
> > We are starting the information verification of this case/root case, and
> > please provide the information which marked "NEED CA Response" in attachment
> > as Comment#6.
> > 
> > Note:
> > For test website, please refer to the following statement and provide
> > valid/revoke/expired test site.
> > CA Browser Forum section 2.2: “The CA SHALL host test Web pages that allow
> > Application Software Suppliers to test their software with Subscriber
> > Certificates that chain up to each publicly trusted Root Certificate. At a
> > minimum, the CA SHALL host separate Web pages using Subscriber Certificates
> > that are (i) valid, (ii) revoked, and (iii) expired.”
> > 
> > Thank you!
> > 
> > Kind regards,
> > Aaron
> 
> Dear Aaron,
> 
>    There are some links for your testing:
> 
>     EV SSL Certificates:
>     
>        Valid:  https://ev.hinet.net/ 
> 
>        Expired：https://ra.testev.hinet.net
> 
>        Revoked：https://testev.hinet.net   
> 
>     OV SSL Certificates:
>     Valid: https://testpublicca.hinet.net 
> 
> 
>      Note that  ePKI EV SSL Certification Authority - G1 has accomplished
> Trust Service Principles and Criteria for Certification Authorities Version
> 2.0、WebTrust Principles and Criteria for Certification Authorities-Extended
> Validation SSL Version 1.4.5 & SSL Baseline with Network Security – ßVersion
> 2.2 (and Version 2.0) audit recently.
> 
>     The URL of seals are as below
> 
>      WebTrust (standard audit) : https://cert.webtrust.org/ViewSeal?id=2277
>         
>      WebTrust  EV : https://cert.webtrust.org/ViewSeal?id=2279
> 
>      WebTrust SSL BR : https://cert.webtrust.org/ViewSeal?id=2278
> 
> Sincerely Yours,
> 
>                 Li-Chun Chen

Comment 12

[Aaron Wu]

Hi Li-Chun,

Thanks to provide Audit Statements and Test websites.

Audit statements look good, thanks!


There are several items need your update:

1. For root test websites, the test result of expired and revoked websites is not as expected. Could you please kindly double check? the valid website is fine to me. (Please also see my comment in audit case)

2. Please provide BR Self Assessment, which mentioned in Comment#10

3. For more information we need, I listed down the summary attached in Comment#6, please provide the answer which shown "Need Response From CA"


Please kindly provide the information above and we can keep this request moving forward.

Thank you so much!

Kind Regards,
Aaron

Comment 13

[Li-Chun CHEN]

Hi, Aaron,

     For root test websites.

      The expired and revoed   EV SSL websites is workable. 
      
          Expired：https://ra.testev.hinet.net

          Revoked：https://testev.hinet.net   


But for Expired OV SSL certificate website：https://testfca.hinet.net and  revoked website：https://testpublicca.hinet.net, Originally webmaster installed the expired and revoked certificates for Browser's testing. But our headquarter arranges scan of the company's websites from September 12. Before September 12,  IS department of our branch also scanned these two OV SSL certificates for self-checking, and the staff of IS department asked the webmaster to fix the problem such as "SSL certificate invalid date", so the webmaster temporarily installed the valid certificates yesterday to replace the expired and revoked SSL certificates. After the end of the scan of the headquarter, the webmaster will install a valid certificates. We will tell you.  I will attach expired and revoked OV certificates as compressed files for your reviewing.   

Sincerely Yours,

           Li-Chun

(In reply to Aaron Wu from comment #12)
> Hi Li-Chun,
> 
> Thanks to provide Audit Statements and Test websites.
> 
> Audit statements look good, thanks!
> 
> 
> There are several items need your update:
> 
> 1. For root test websites, the test result of expired and revoked websites
> is not as expected. Could you please kindly double check? the valid website
> is fine to me. (Please also see my comment in audit case)
> 
> 2. Please provide BR Self Assessment, which mentioned in Comment#10
> 
> 3. For more information we need, I listed down the summary attached in
> Comment#6, please provide the answer which shown "Need Response From CA"
> 
> 
> Please kindly provide the information above and we can keep this request
> moving forward.
> 
> Thank you so much!
> 
> Kind Regards,
> Aaron

Comment 14

[Li-Chun CHEN]

Hi, Arron,

  It seems that at this time, I can't attached the OV revoked and expired SSL Certificates. But I e-mail a compressed file to you several hours ago. When the webmaster re-install the revoked and expired SSL Certificates to those site after our company fininsh the scan, then I will tell you. 

Sincerely Yours,

       Li-Chun Chen

Comment 15

[Aaron Wu]

Thanks Li-Chun!

Please kindly let me know once your webmaster re-install the revoked and expired SSL Certificates to test websites, then I can continue to work on this request.

Kind Regards,
Aaron

Comment 16

[Li-Chun CHEN]

Dear Aaron,

The webmaster re-installed the revoked and expired SSL Certificates to test websites agian as below

Expired OV SSL certificate website：https://testfca.hinet.net and  revoked website：https://testpublicca.hinet.net

Please connect above two websites again.


Sincerely Yours,

       Li-Chun

Comment 17

[Aaron Wu]

Hi Li-Chun,

Thanks for for your update!

However, I tried to verify expired and revoked website in Comment#16. Here is the test result
   - Expired OV SSL certificate website：https://testfca.hinet.net, it shows SEC_ERROR_REVOKED_CERTIFICATE
   - revoked website：https://testpublicca.hinet.net, it is unable to connect

Please kindly check both sites and fix, thank you!

Best Regards,
Aaron

Comment 18

[Li-Chun CHEN]

(In reply to Aaron Wu from comment #17)
> Hi Li-Chun,
> 
> Thanks for for your update!
> 
> However, I tried to verify expired and revoked website in Comment#16. Here
> is the test result
>    - Expired OV SSL certificate website：https://testfca.hinet.net, it shows
> SEC_ERROR_REVOKED_CERTIFICATE
>    - revoked website：https://testpublicca.hinet.net, it is unable to connect
> 
> Please kindly check both sites and fix, thank you!
> 
> Best Regards,
> Aaron


Dear Aaron,

   Sorry. Expired OV SSL certificate website should be https://testpublicca.hinet.net. The webmaster restart it.

          Revoked  OV SSL certificate website： https://testfca.hinet.net 

          Would you mind verifying above two sites again?  The webmaster said he insatlled  (SSL → PublicCA -G2 →eCA -G2)this afternoon. So you will see SEC_ERROR_UNKNOWN_ISSUER in firefox ，not SEC_ERROR_REVOKED_CERTIFICATE. Because eCA -G2 has not yet included in Mozilla NSS.

Sincerely Yours,

           Li-Chun

Comment 19

[Aaron Wu]

Hi Li-Chun,

As discussed during CAB Forum 42 Meeting, you mentioned Chunghwa Telecom plan tocover EV treatment in ePKI Root Certification Authority - G2. Please add related information and comment by using this bug.

And note that once EV treatment included, you need to provide corresponding Test websites (Valid/Revoked/Expired) with EV SSL.

Please feel free to let me know if any further question, thank you!


Kind Regards,
Aaron

Comment 20

[Li-Chun CHEN]

Dear Aaron,  

    The EV  treatment should be ePKI Root Certification Authority - G2(SHA-1 Thumbprint:d9 9b 10 42 98 59 47 63 f0 b9 a9 27 b7 92 69 cb 47 dd 15 8b) plus the included Root CA - ePKI Root Certification Authority (SHA-1 Thumbprint:67 65 0d f1 7e 8e 7e 5b 82 40 a4 f4 56 4b cf e2 3d 69 c6 f0) , Please see https://bugzilla.mozilla.org/show_bug.cgi?id=448794. 

    The corresponding test websites (Valid/Revoked/Expired) with EV SSL are as below

1. Vaild:https://ev.hinet.net 
 
   The certificate chian in above URL are an EV SSL Certificate--->ePKI EV SSL Certification Authority -
G1(SHA-1 Thumbprint: 81 ac 5d e1 50 d1 b8 de 5d 3e 0e 26 6a 13 6b 73 78 62 d3 22) ----->ePKI Root Certification Authority - G2 crosssigned by ePKI Root Certification Authority  (SHA-1 Thumbprint:c3 ca f8 57 0c b1 2d d0 fc 97 37 bf cd 0f 08 7c 9b e6 d2 81, it is an self-issued certificate as defined in RFC 5280)     
      

  2.Revoked: https://testev.hinet.net

   The certificate chian in above URL are an EV SSL Certificate--->ePKI EV SSL Certification Authority -
G1(SHA-1 Thumbprint: 81 ac 5d e1 50 d1 b8 de 5d 3e 0e 26 6a 13 6b 73 78 62 d3 22) ----->ePKI Root Certification Authority - G2(SHA-1 Thumbprint:d9 9b 10 42 98 59 47 63 f0 b9 a9 27 b7 92 69 cb 47 dd 15 8b) 


   3.Expired: https://ra.testev.hinet.net


   The certificate chian in above URL are an EV SSL Certificate--->ePKI EV SSL Certification Authority - G1(SHA-1 Thumbprint: 81 ac 5d e1 50 d1 b8 de 5d 3e 0e 26 6a 13 6b 73 78 62 d3 22) ----->ePKI Root Certification Authority - G2(SHA-1 Thumbprint:d9 9b 10 42 98 59 47 63 f0 b9 a9 27 b7 92 69 cb 47 dd 15 8b) 

   I found in https://wiki.mozilla.org/CA:How_to_apply#Enable_EV_for_an_included_root , thee is a sentance "Note: EV-enablement is done in a separate bug, after the root has been included." , so that was my question that if we also want to EV treatment for  ePKI Root Certification Authority, do we need another bug? 
   

Sincerely Yours,

     Li-Chun

Comment 21

[Aaron Wu]

Hi Li-Chun,

Thanks for your EV information.

An error occurred when running https://certificate.revocationcheck.com/ev.hinet.net
  
- Content-Type in response is not set to 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section 4.2.1.13)


Please help to check and fix, thanks!

Kind Regards,
Aaron

Comment 22

[Li-Chun CHEN]

Dear Aaron,
 
   Now we fix the error. Please run https://certificate.revocationcheck.com/ev.hinet.net,

Now  Content-Type in response is set to 'application/pkix-crl (RFC 5280, section 4.2.1.13)'

     Thank you!

Sincerely Yours,

Li-Chun

Comment 23

[Li-Chun CHEN]

Attachment: ePKI CP v1.4 English Version

Dear Aarno,

     Attached file is Certificate Policy for the Chunghwa Telecom ecommerce Public Key Infrastructure Version 1.4 English Version. 

     Also you can download it from our repository: http://eca.hinet.net/download/ePKI_CP_v1.4_final(Eng).pdf

Sincerely Yours,

       Li-Chun

Comment 24

[Aaron Wu]

Hi Li-Chun,

As we discussed, the updated CP v1.5 is coming out, and up-to-date CPS as well. Please upload those documents in this bug once they are available.

Thanks,
Aaron

Comment 25

[Li-Chun CHEN]

Attachment: eCA_CPS_v1.4 _Eng(20170716).pdf

Comment 26

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.7_Eng(20170714).pdf

Comment 27

[Li-Chun CHEN]

Attachment: ePKI_EVSSL_CA_CPS_v1.1_Eng(20170714).pdf

Comment 28

[Li-Chun CHEN]

(In reply to Aaron Wu from comment #24)
> Hi Li-Chun,
> 
> As we discussed, the updated CP v1.5 is coming out, and up-to-date CPS as
> well. Please upload those documents in this bug once they are available.
> 
> Thanks,
> Aaron

Dear Aaron,

   CPSs approved by ePKI Policy Management Committee and sent to Ministry of Economic Affairs (MOEA) in accordance with Article 11 of Taiwan's Electronic Signatures Act.  After 20170627meeting’s reviewing, then we sent to MOEA again on July 19，including below three CPSs that are translated in English Version :
1.ePKI Root Certification Authority Certification Practice Statement Version 1.4 (Draft, Issue Date:2017/07/16)。
2.ePKI EV SSL Certification Authority Certification Practice Statement of Chunghwa Telecom Version 1.1 (Draft, Issue Date:2017/07/14)。
3. Public Certification Authority Certification Practice Statement of Chunghwa Telecom Version 1.7 (Draft, Issue Date:2017/7/14)。 

   Now I upload these documents for your reviewing. Also we have disclosed in eCA's Repository in https://eca.hinet.net/en/repository_a.htm or you can download the zip file in http://eca.hinet.net/download/ePKI_CPS(20170719).zip.  The Tradtional Chinese Version is already disclosured.

Sincerely Yours,

         Li-Chun Chen

Comment 29

[Li-Chun CHEN]

Attachment: eCA_CPS_v1.4 _Eng(20171023).pdf

Comment 30

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.7_Eng(20171023).pdf

Comment 31

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.7_Eng(20171023).pdf

Comment 32

[Li-Chun CHEN]

Dear Aaron,

   After reading BR assessment and other discussion in Bugzilla@Mozilla and Adobe new AATL Technical Requirement 2.0. We wanted to amend three CPSs. We told the public servants of the Ministry of Economic Affairs, Ms. Shu, that please hold the approving of three CPSs that we sent on July 19.

   We disclose more details in Chapter 2,3, 4, 5, 6, 7 and 9 in CPSs. After approving by ePKI Policy Management Committe,  we finally sent three newer CPSs on Oct. 24 and tranlated to English Versions as below.

1. ePKI Root Certification Authority Certification Practice Statement Version 1.4 (Draft, Issue Date:2017/10/23)

2. ePKI EV SSL Certification Authority Certification Practice Statement of Chunghwa Telecom Version 1.1 (Draft, Issue Date:2017/10/23)。

3. Public Certification Authority Certification Practice Statement of Chunghwa Telecom Version 1.7 (Draft, Issue Date:2017/10/23)。


    The review Committee organized by  Ministry of Economic Affairs reviewed our CPSs and gave us comments on Dec. 4. We have amended the CPSs and sent to MOEA today.  After the confirmation, they will have  approval versions of CPSs. But the new public servant Mr. Wu of the Ministry of Economic Affairs who took over Ms Shu's job in Oct. told me the version number of three CPSs that will be approved should be the same as that we sent to MOEA in July and in October. So the difference will be files names with different dates, the content of these CPS and the date of the cover and section 1.2 of these CPSs. Also, there will be Competent Authority Approval Number in Abstract of the three CPSs in comparision with the versions in July and Oct..

    After MOEA's final approving, we will translate them to English version. But the differnce should be few. All these CPSs are published in the repository in Traditional Chinese version and English Versions. You can see the Oct version from above attachment or download the zip files from http://eca.hinet.net/download/ePKI_EVSePKI_CPS(20171024).zip


   ePKI Policy Management Committe approved ePKI CP Version 1.5 on Dec., 1 meeting. The tradtional Chinese version is in the repository as https://eca.hinet.net/download/ePKI_CP_v1.5_final.pdf . After translating and reviewing to English version, I will upload the English version as soon as possible.

Sincerely Yours,

          Li-Chun Chen

Comment 33

[Li-Chun CHEN]

Attachment: ePKI_CP_v1.4_final(Eng).pdf

Because there are some typo or tranlsation error in section 1.3.2.1, 6.3.2.1 and 6.3.2.3 of ePKI CP V1.4 English Version, so use this file to replace the original one. Thanks!

Li-Chun Chen

Comment 34

[Li-Chun CHEN]

(In reply to Li-Chun CHEN from comment #32)
> Dear Aaron,
> 
>    
> the Oct version from above attachment or download the zip files from
> http://eca.hinet.net/download/ePKI_EVSePKI_CPS(20171024).zip
> 
> 


  The Oct. version  link is fixed to http://eca.hinet.net/download/ePKI_EVSePKI_CPS(20171024).zip . Thanks!


>           Li-Chun Chen

Comment 35

[Li-Chun CHEN]

Attachment: eCA_CPS_v1.4 _Eng(20171023).pdf

This file corrects lack of "at least every 12 months" at section 4.9.10.

Comment 36

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 37

[Li-Chun CHEN]

Attachment: ePKI_CP_v1.5(Eng).pdf

Dear Aaron,
 
   Attached files are ePKI CP Version 1.5 English version. You also can download it from https://eca.hinet.net/download/ePKI_CP_v1.5(Eng).pdf  

Sincerely Yours,

Li-Chun Chen

Comment 38

[Kathleen Wilson]

Attachment: BR-Self-Assessment-Chunghwa-Feb5-2018.xlsx

Comment 39

[Li-Chun CHEN]

Attachment: BR-Self-Assessment-Chunghwa-March18-2018.xlsx

Comment 40

[Li-Chun CHEN]

Attachment: ePKI Root Certification Authority Certification Practice Statement (eCA CPS) Version 1.4 (20180214)

Comment 41

[Li-Chun CHEN]

Attachment: Public Certification Authority Certification Practice Statement of Chunghwa Telecom (PublicCA CPS) Version 1.7 (20180214)

Comment 42

[Li-Chun CHEN]

Attachment: ePKI EV SSL Certification Authority Certification Practice Statement of Chunghwa Telecom (ePKI EV SSL CA CPS or EV SSL CA CPS) Version 1.1 (20180214)

Comment 43

[Kathleen Wilson]

Attachment: 1341604-CA-Information-March19-2018.pdf

Comment 44

[Kathleen Wilson]

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Comment 45

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.7(Eng)20180214.pdf

There are some typo in page i about CPS version control. ("1.1" should be replaced with "1.7')

Comment 46

[Li-Chun CHEN]

Attachment: eCA_CPS_v1.4_Eng.pdf

ePKI Root Certification Authority Certification Practice Statement (eCA CPS) Version 1.4 (Add Competent Authority Approval No.: Chin-Shang-Tzu No. 10702216460 in Abstract.)

Comment 47

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.7_Eng.pdf

Public Certification Authority Certification Practice Statement of Chunghwa Telecom (PublicCA CPS) Version 1.7 (Add Competent Authority Approval No.: Chin-Shang-Tzu No. 10702216460 in Abstract.)

Comment 48

[Li-Chun CHEN]

Attachment: ePKI_EVSSL_CA_CPS_v1.1_Eng.pdf

ePKI EV SSL Certification Authority Certification Practice Statement of Chunghwa Telecom (ePKI EV SSL CA CPS or EV SSL CA CPS) Version 1.1 (Add Competent Authority Approval No.: Chin-Shang-Tzu No. 10702216460 in Abstract.)

Comment 49

[Li-Chun CHEN]

Attachment: BR-Self-Assessment-Chunghwa-March24-2018.xlsx

The difference of ths version of BR Self-Assessment in comparision with coment 39 (BR-Self-Assessment-Chunghwa-March18-2018.xlsx) is only  the download URL in CA sites of these three CPS in comment 46, 47, 48 in the "introduction" of BR Self-Assessment.  Thanks.

Comment 50

[Wayne Thayer]

Dear Li-Chun,

I have begun to review your root inclusion request, and I have some questions/concerns:
1. BR section 2.2 requires the publication of CAA Issuer Domain Names in the CP/CPS. I am unable to find this in any of your CP/CPS documents.
2. Can you provide the WebTrust, BR, and EV audit statements for this root and the intermediates covering the audit period prior to August 15, 2016?
3. Many misissuances are found for certificates issued from this root: https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01 Some are incorrect (false positive) because the certificate is for code signing or OCSP signing, but many other reported errors are correct. Here is a recent example: https://crt.sh/?id=380838922&opt=x509lint,cablint,zlint 

Questions:
- Is there an explanation for each of these errors?
- Do you plan to remediate and revoke these certificates?
- What has been done to prevent these problems in the future?

Recent root inclusion requests for roots and intermediates that have issued certificates containing these types of errors have been rejected and the CA has been asked to submit a new root. Please tell me if you would like me to continue with a public discussion on this request, or if you would prefer to stop this request and submit a new root.

Sincerely,

Wayne

Comment 51

[Li-Chun CHEN]

Attachment: CHT_eCA_PublicCA_WTCA 2.0_Seal File_2016.pdf

In replying comment 50, The WebTrust audit statements for this root and the intermediates covering the audit period prior to August 15, 2016 is attached as CHT_eCA_PublicCA_WTCA 2.0_Seal File_2016.pdf.

Comment 52

[Li-Chun CHEN]

Attachment: CHT_eCA_PublicCA_WTCA 2.0_SSL BR 2.0_Seal File_2016.pdf

For comment 50, The BR audit statements for this root and the intermediates covering the audit period prior to August 15, 2016 is as attachment. Thanks. 
 
     Li-Chun

Comment 53

[Li-Chun CHEN]

Attachment: Replying-to-Mozillabugzilla-20180509.pdf

Explanation and notes for questions 3 of comment 50.

Comment 54

[Li-Chun CHEN]

(In reply to Wayne Thayer [:wayne] from comment #50)
> Dear Li-Chun,
> 
> I have begun to review your root inclusion request, and I have some
> questions/concerns:
> 1. BR section 2.2 requires the publication of CAA Issuer Domain Names in the
> CP/CPS. I am unable to find this in any of your CP/CPS documents.
> 2. Can you provide the WebTrust, BR, and EV audit statements for this root
> and the intermediates covering the audit period prior to August 15, 2016?
> 3. Many misissuances are found for certificates issued from this root:
> https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
> Some are incorrect (false positive) because the certificate is for code
> signing or OCSP signing, but many other reported errors are correct. Here is
> a recent example: https://crt.sh/?id=380838922&opt=x509lint,cablint,zlint 
> 
> Questions:
> - Is there an explanation for each of these errors?
> - Do you plan to remediate and revoke these certificates?
> - What has been done to prevent these problems in the future?
> 
> Recent root inclusion requests for roots and intermediates that have issued
> certificates containing these types of errors have been rejected and the CA
> has been asked to submit a new root. Please tell me if you would like me to
> continue with a public discussion on this request, or if you would prefer to
> stop this request and submit a new root.
> 
> Sincerely,
> 
> Wayne

Dear Wayne,

1. For question 1 in comment 50, in ePKI CP V1.5 section 1.3.2.2 Subordinate CA,
 
As the PublicCA signs the Organization Validation (OV) SSL certificates and the EV SSL CA signs the Extended Validation (EV) SSL certificates, the information of “pki.hinet.net” in the certification authority authorization (CAA) records represents that the CAs able to sign SSL certificates in the ePKI. The website, https://pki.hinet.net, includes description pages.

  We think we will add in next version of Public CA CPS section 4.2.1 as below sentence.

The CAA Issuer Domain Names for Public CA within  Chunghwa Telecom's operational control are “pki.hinet.net”and“publicca.hinet.net".

  We think we will add in next version of ePKI EV SSL CA CPS section 4.2.1 as below:

The CAA Issuer Domain Names for ePKI EV SSL  CA within Chunghwa Telecom's operational control are “pki.hinet.net,“ev.hinet.net” and "evssl.hinet.net".

  We think we will add in next version of eCA CPS section 4.2.1 as below:

The CAA Issuer Domain Names for CAs under ePKI Root CA within  Chunghwa Telecom's operational control are "pki.hinet.net", "eca.hinet.net", "publicca.hinet.net", "ev.hinet.net", "evssl.hinet.net" and 
"epki.com.tw"

There was a typo in section 1.3.2.2 about “Extended” Validation of ePKI CP Version 1.5. We have updated ePKI CP version 1.5 in CA’s repository. The correct version is in https://eca.hinet.net/download/ePKI_CP_v1.5(Eng).pdf  

   2. For question 2, please see attachment of comment 51 and comment 52 about WebTrust, BR audit statement for  this root and the intermediates covering the audit period prior to August 15, 2016. There are no EV audit statements for this root and the intermediates covering the audit period prior to August 15, 2016. But we have an EV readiness check audit statement as https://eca.hinet.net/download/CHT_EV_SSL_CA_ReadinessCheckReportsAndAssertions.pdf. 

    3. For questions 3, please see attachment of comment 53 about explanation and notes. As for a recent example: https://crt.sh/?id=380838922&opt=x509lint,cablint,zlint, it is not a SSL certificate. Also the certificate is revoked this afternoon.

    Thank you.

Sincerely Yours,

     Li-Chun Chen

Comment 55

[Wayne Thayer]

Dear Li-Chun,

Thank you for this information. I have just moved this request into the public discussion phase of our process. My message included the findings listed below. Please follow along and respond to questions on the mozilla.dev.security.policy forum.

==Good==
* Clean WebTrust & BR audit statements cover periods back to the creation of this root in 2015.
* The CPSs properly document 825 day maximum validity periods, and change logs were recently added.

==Meh==
* Both of the domain validation methods that will be deprecated on 1-August are currently listed as in-use in the root CP/CPS
* CAA Issuer Domain Names are only specified in the root CP, in section 1.3.2.2 rather than 2.2.
* For domain validation, each CPS does not state which subsection of BR 3.2.2.4 it is complying with as recommended by our policy.
* There is, in my opinion, an excessive amount of duplication of information between the CP and 3 CPSs (over 600 pages in total), making the review of these docs difficult and tedious.

==Bad==
* A large number of certificates have been misissued from the “Public Certification Authority - G2” intermediate [4] (recent example: [2]). Many of these certificates remain valid. Chunghwa Telecom has published a response to these errors [3] in the inclusion bug. My main concern with the response is the assertion that some of these are not SSL certificates bound to follow the BRs because they do not contain the CAB Forum OV OID in the certificate policies extension. This assertion contradicts section 1.1 of Mozilla policy.

[1] https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
[2] https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint
[3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418

Comment 56

[Li-Chun CHEN]

Attachment: ePKI CP V1.6

Certificate Policy for the Chunghwa Telecom ecommerce Public Key Infrastructure Version 1.6. (ePKI CP Version 1.6)

Comment 57

[Li-Chun CHEN]

Attachment: eCA CPS version 1.5

ePKI Root CA's CPS version 1.5.

Comment 58

[Li-Chun CHEN]

Attachment: ePKI EVSSL CA CPS version 1.2

Comment 59

[Li-Chun CHEN]

Attachment: PublicCA CPS Version 1.8

Comment 60

[Li-Chun CHEN]

(In reply to Wayne Thayer [:wayne] from comment #55)
> Dear Li-Chun,
> 
> Thank you for this information. I have just moved this request into the
> public discussion phase of our process. My message included the findings
> listed below. Please follow along and respond to questions on the
> mozilla.dev.security.policy forum.
> 
> ==Good==
> * Clean WebTrust & BR audit statements cover periods back to the creation of
> this root in 2015.
> * The CPSs properly document 825 day maximum validity periods, and change
> logs were recently added.
> 
> ==Meh==
> * Both of the domain validation methods that will be deprecated on 1-August
> are currently listed as in-use in the root CP/CPS
> * CAA Issuer Domain Names are only specified in the root CP, in section
> 1.3.2.2 rather than 2.2.
> * For domain validation, each CPS does not state which subsection of BR
> 3.2.2.4 it is complying with as recommended by our policy.


Dear Wayne,

  I attached current CP and 3CPSs in previous comments .

  Both of the domain validation methods that will be deprecated on August 1 are not used now. Please see Section 3.2.5 of CPSs of two Sub-CAs. (ePKI EVSSL CA CPS version 1.2 and PublicCA CPS Version 1.8). For domain validation, Section 3.2.5 of these two CPSs state which subsection of BR 3.2.2.4 it is complying with as recommended by Mozilla Root Store Policy.

As for CP and 3 CPS about CAA issuer domain names.
Please see Section 1.3.2.2 and Section 4.2.1 of ePKI CP Version 1.6. 
Please see Section 2.2 of ePKI Root CA(eCA) CPS version 1.5. 
Please see Section 2.2 and Section 4.2.1.1 of ePKI EV SSL CA Version 1.2.
Please see Section 2.2 and Section 4.2.1 of PublicCA CPS Version 1.8.

   Because our president of Data Communications Business Group, Chunghwa Telecom Co., Ltd. went abroad for three weeks. After he went back to Taiwan, he approved the reorganization of Policy Management Committee (See Section 1.3.1 of ePKI CP) on May 21.  Policy Management Committee approved the amended CP and 3 CPSs on May 28. Thanks for your reviewing about CP and 3CPSs.

Sincerely Yours,

    Li-chun

Comment 61

[Li-Chun CHEN]

Attachment: 10 dedicated_server_application_software_to_be-revoked-and reissued

Comment 62

[Li-Chun CHEN]

(In reply to Wayne Thayer [:wayne] from comment #55)
> Dear Li-Chun,
> 
> Thank you for this information. I have just moved this request into the
> public discussion phase of our process. My message included the findings
> listed below. Please follow along and respond to questions on the
> mozilla.dev.security.policy forum.
> 

> 
> ==Bad==
> * A large number of certificates have been misissued from the “Public
> Certification Authority - G2” intermediate [4] (recent example: [2]). Many
> of these certificates remain valid. Chunghwa Telecom has published a
> response to these errors [3] in the inclusion bug. My main concern with the
> response is the assertion that some of these are not SSL certificates bound
> to follow the BRs because they do not contain the CAB Forum OV OID in the
> certificate policies extension. This assertion contradicts section 1.1 of
> Mozilla policy.
> 
> [1]
> https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
> [2] https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint
> [3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418

Dear Wayne,

   We have already paused the issuance of this type of certificate in argue, i.e., dedicated server application software certificate.

   There are 10 such type of certificates that are still valid, as listed in the attached file of comment #61.

   By the way, the certificate of 綠金石平台(https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint) that Mozilla mentioned in Ref [2] of Comment 55 was revoked on May 21th this year, and hence not listed in this attached file.

   All these 10 certificates are used by the systems owned by our company, i.e., Chunghwa Telecom Co., Ltd..

   Although these 10 certificates have a SubjectAltnativeName that includes DNSName, they are never used as SSL certificates. Here are our solutions for handling these 10 certificates.

1. We plan to modify the format of this type of certificate. The new certificate format will contain an EKU that excludes anyPolicy, emailProtection and serverAuth; besides, there will be no SubjectAltName anymore. In other words, neither DNSName nor IPAddress will be included in this type of certificate.
2. We plan to notify the owners of the 10 certificates to make an application for revoking their original certificates and re-issuing a new one according to the new format.
     
   After discussing with the owners of the 10 dedicated server application software certificates, they are all willing to re-issue these certificates with the new format and revoke the old ones. However, before that we still have some work to do, such as system modification, electronic process, and so on.

   We plan to finish the re-issuing and revocation processes of all these 10 certificates before early July.  Of course we will also report immediately if we finish that in advance. 

   Thank you.

Sincerely Yours,

           Li-Chun

Comment 63

[Li-Chun CHEN]

(In reply to Li-Chun CHEN from comment #62)

> 1. We plan to modify the format of this type of certificate. The new
> certificate format will contain an EKU that excludes anyPolicy,
> emailProtection and serverAuth; besides, there will be no SubjectAltName
> anymore. In other words, neither DNSName nor IPAddress will be included in
> this type of certificate.

 We mean that the new certificate format will contain an EKU that doesn’t include anyPolicy, emailProtection or serverAuth in it. Thanks.

   Li-Chun

Comment 64

[Li-Chun CHEN]

Attachment: dedicated_server_application_software_certificate-20180607.docx

Comment 65

[Li-Chun CHEN]

(In reply to Li-Chun CHEN from comment #64)
> Created attachment 8984073 [details]
> dedicated_server_application_software_certificate-20180607.docx

Dear Wayne,


   After furthermore investigating these 10 dedicated server application software certificates, we found that 5 of them are not in use now.

   So these subscribers applied for revoking their certificates, and the RA officer of this certificate group revoked these 5 certificates in advance and we updated the file as attached. 

   As you can see in that file of comment 64, the Status column of these 5 certificates are marked as ‘revoked’ with the revocation time in the parentheses.

   As for the rest 5 valid certificates, we will also revoke them once their new certificates with the new format is issued, as we planned before.

Sincerely Yours,

       Li-Chun

Comment 66

[Li-Chun CHEN]

 Our two customers requested to use original CSR to issue two shorter validity SSL certificates. By the re-issuance function of a program, to insert original applications data, our SSL RA Officers checked the addresses but they forgot to add L in Subject DN. So there are two SSL Certificates as below lack of L or S in Subject DN.
 
1.Serial Number:20BD5F0B51809E44C0718AB133CA5E78 CN=*.sercomm.com, O=中磊電子股份有限公司, C=TW or https://crt.sh/?id=508868868
 
2.Serial Number:3CE33A6D8899A211FB2D296D9E0B69CB CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, C=TW or https://crt.sh/?id=512788172
 Dear Wayne,

  Our researchers of  Telecommunication Laboratories of Chunghwa Telecom found above issue on June 11 and told our SSL RA Officers to contact the customers. When I was back to my office after the traveling from England and discussed with my colleagues, I mailed the situation and the plan to Wayne and  Kathleen offline on June 15.

  This certificate of https://crt.sh/?id=512788172 was revoked on June 11 soon.
 
  We have re-issued new certificates for two customers as below:
 
42664EEA106F2CBF736ADBF949D4218F CN=*.sercomm.com, O=中磊電子股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=519100183
 
100079C87402938109A5FEC040C5BE0F CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=549539943
  
  After our customer installed a new certificate (https://crt.sh/?id=519100183) in their web servers, network equipment and firewall, The certificate of https://crt.sh/?id=508868868 was revoked on June 21,.
 
  The checking function of Subject DN about either L or S  are online June 22.  I mailed to Wayne and  Kathleen on June 22.
 
  We confirm that the problem has been solved and will not happen in the future. 
 
   As we have discussed in CABF, Taiwan is a small country without state/provinces. We follow X.500, X.520 and Taiwan’s government’s DIT for the certificates. We can unique identify the subject without state/provinces and locality in DN for a central government agency or a company. (For example, In Taiwan's Company Act, https://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001, Article 18  No company may use a corporate name which is identical with that of another company. ). We really received some subscribers of central government agency or a company asked why your CA adds L in the subject DN of an SSL certificate. We explained that we follow the BR about either L or S should be in Subject DN now. 

Sincerely Yours,

             Li-Chun Chen

Comment 67

[Li-Chun CHEN]

Attachment: proprietary_server_application_software_certificate.docx

Comment 68

[Li-Chun CHEN]

Attachment: NewCertificates.zip

Comment 69

[Li-Chun CHEN]

(In reply to Li-Chun CHEN from comment #62)
> (In reply to Wayne Thayer [:wayne] from comment #55)
> > Dear Li-Chun,
> > 
> > Thank you for this information. I have just moved this request into the
> > public discussion phase of our process. My message included the findings
> > listed below. Please follow along and respond to questions on the
> > mozilla.dev.security.policy forum.
> > 
> 
> > 
> > ==Bad==
> > * A large number of certificates have been misissued from the “Public
> > Certification Authority - G2” intermediate [4] (recent example: [2]). Many
> > of these certificates remain valid. Chunghwa Telecom has published a
> > response to these errors [3] in the inclusion bug. My main concern with the
> > response is the assertion that some of these are not SSL certificates bound
> > to follow the BRs because they do not contain the CAB Forum OV OID in the
> > certificate policies extension. This assertion contradicts section 1.1 of
> > Mozilla policy.
> > 
> > [1]
> > https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
> > [2] https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint
> > [3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418
> 
> Dear Wayne,
> 
>    We have already paused the issuance of this type of certificate in argue,
> i.e., dedicated server application software certificate.
> 
>    There are 10 such type of certificates that are still valid, as listed in
> the attached file of comment #61.
> 
>    By the way, the certificate of
> 綠金石平台(https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint) that Mozilla
> mentioned in Ref [2] of Comment 55 was revoked on May 21th this year, and
> hence not listed in this attached file.
> 
>    All these 10 certificates are used by the systems owned by our company,
> i.e., Chunghwa Telecom Co., Ltd..
> 
>    Although these 10 certificates have a SubjectAltnativeName that includes
> DNSName, they are never used as SSL certificates. Here are our solutions for
> handling these 10 certificates.
> 
> 1. We plan to modify the format of this type of certificate. The new
> certificate format will contain an EKU that excludes anyPolicy,
> emailProtection and serverAuth; besides, there will be no SubjectAltName
> anymore. In other words, neither DNSName nor IPAddress will be included in
> this type of certificate.
> 2. We plan to notify the owners of the 10 certificates to make an
> application for revoking their original certificates and re-issuing a new
> one according to the new format.
>      
>    After discussing with the owners of the 10 dedicated server application
> software certificates, they are all willing to re-issue these certificates
> with the new format and revoke the old ones. However, before that we still
> have some work to do, such as system modification, electronic process, and
> so on.
> 
>    We plan to finish the re-issuing and revocation processes of all these 10
> certificates before early July.  Of course we will also report immediately
> if we finish that in advance. 
> 
>    Thank you.
> 
> Sincerely Yours,
> 
>            Li-Chun


Dear Wayne,

   After re-issuing and testing the new certificates with the new format by those applications, the rest 5 proprietary server application software certificates [1] are also revoked. 

   So we update the information for these certificates in the attached file  (https://bugzilla.mozilla.org/attachment.cgi?id=8991008 in Comment https://bugzilla.mozilla.org/show_bug.cgi?id=1341604#c67)

   As you can see in that file, all the Status column are already marked as ‘revoked’ with the revocation time in the parentheses.

   Besides, the information of the new certificates with the new format are specified in the New Certificate column.

   We also provide these new certificates as attached zip fil(https://bugzilla.mozilla.org/attachment.cgi?id=8991015 in https://bugzilla.mozilla.org/show_bug.cgi?id=1341604#c68) for your reference.

[1]We call them "dedicated server application software certificates" before, but these certificates are using  propriety protocol (unlike TLS protocol, are widely using protocol). After discussing with my colleague and you, we call them "proprietary server application software certificates"  to communicate the fact that these certificates are not for SSL and are not BR-compliant. 
     

Sincerely Yours,

                   Li-Chun Chen
                   Chunghwa Telecom

Comment 70

[Wayne Thayer]

Emailed mozilla.dev.security.policy requesting comments by 16-July.

Comment 71

[Li-Chun CHEN]

Attachment: PublicCA_CPS_v1.8_Eng.pdf We use “proprietary” server application certificates to replace “dedicated” server application certificates in Public CA CPS V1.8 English version. For a better tranlation.

Comment 72

[Wayne Thayer]

While I sincerely appreciate the efforts of Chunghwa Telecom to respond to questions and to remediate some of the issues that were identified here, the discussion [1] has made it clear that this request should be denied. There is a significant degree of misissuance associated with this root, some of the misissuance was intentional, and remediation did not occur until the problems were called out. I am resolving this bug as WONTFIX. Chunghwa Telecom is encouraged to create a new root that is free of these issues and to apply for the inclusion of that new root in the Mozilla program.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/W4VK1JPgiZA/tFHqH5JYCgAJ