1065896 - Apply Taiwan Government root certificate included in mozilla

Status: RESOLVED WONTFIX

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

Description

[National Development Council]

Attachment: 20140812_Mozilla Check List_CA.docx

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.103 Safari/537.36

Steps to reproduce:

The CA is operated by government located in Taipei City, ROC.
And We are already the member of Mozilla’s CA Certificate Program. ( The browser, Firefox, has included our Root Certificate, called Taiwan GRCA) (See. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/)
Now, we want to include new root that is rollover of a root that is already included in Mozilla.



Actual results:

For example, Most of users use your browser suffering and operating government website, for tax, labor insurance, etc. . So we eager to put our new root certificate in NSS. They can directly trust government website avoiding of phishing


Expected results:

we eager our root certificate to be included in your product. 

If there is any further question, please let me know.

Comment 2

[Kathleen Wilson]

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

Comment 3

[Kathleen Wilson]

Attachment: Initial CA Information Document

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, and provide the necessary information in this bug.

Comment 4

[National Development Council]

Attachment: reply-20141008_Mozilla Check List_CA.docx

Comment 5

[National Development Council]

Dar(In reply to National Development Council from comment #4)
> Created attachment 8520374 [details]
> reply-20141008_Mozilla Check List_CA.docx

Dear Kathleen~

Update information as attachment

If there is any further question, please let me know.

Thanks

NDC

Comment 6

[Kathleen Wilson]

Thanks for the information. This leads to a few more questions...

Are there separate audit statements for each of the subCAs? 
I did not see reference to the subCAs in https://cert.webtrust.org/SealFile?seal=1663&file=pdf

Who audits the subCAs?

Please note that all subordinate CAs also need to be either technically constrained or audited annually as described in Mozilla's CA Certificate Policy. Refer to sections 8, 9, and 10 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


>> The document(s) and section number(s) where the "Commitment to Comply" with 
>> the CA/Browser Forum Baseline Requirements may be found, as per BR #8.3.
>> https://cabforum.org/baseline-requirements-documents/
>
> We will add that in next version, and update it as soon as possible.

I think it also needs to be added to the CPS of any subordinate CA who is capable of issuing SSL certs.


>> SSL Verification Procedures -- Not found in CP or CPS:
>> If you are requesting to enable the Websites Trust Bit, then provide (in
>> English and in publicly available documentation) all the information requested 
>> in #3 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
> 
> It was defined in Subordinate CAs CPS. 

It needs to be added to the CP/CPS that governs all of the subordinate CAs.

Please see:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#CA_Policies_about_Third-Party_Subordinate_CAs
https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs


>>> Email Address Verification Procedures -- Not found in CP or CPS:
>>> If you are requesting to enable the Email Trust Bit, then provide (in
>>> English and in publicly available documentation) all the information requested 
>>> in #4 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
>>
>> We only issue this kind certificate for government and school, as a result, we 
>> can depend on government DNS registered database to verify if they have 
>> ownership/control of the domain name or not rapidly.  
> 
> ANS: We classify end-entity certificates as IC Card, non-IC Card or SSL certificate. 
> Basically IC Card and non-IC Card certificates are same product, they just differ 
> from carrier. User can use that for signing or encrypting email.
>
> And procedure was defined in Subordinate CAs CPS. 

It needs to be added to the CP/CPS that governs all of the subordinate CAs.

Please see:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#CA_Policies_about_Third-Party_Subordinate_CAs


>> Code Signing Subscriber Verification Procedures -- Not found in CP or CPS
>
> ANS: We didn’t issue this one. 

Then, you do not need the Code Signing Trust Bit enabled. Correct?

Comment 7

[National Development Council]

Dear 

We finally finished the annually SSL Baseline requirements audit this year, and get the audit report. (including our root CA and subordinate CAs)
The audit reports are below:

Audit report of Government Root Certification Authority:
http://grca.nat.gov.tw/download/GRCA_WebTrust_for_CAs_Audit_Report.pdf

Audit report of Government Certification Authority: (the subordinate CA which is issuing SSL certificate)
http://gca.nat.gov.tw/download/GCA_WebTrust_for_CAs_Audit_Report.pdf
http://gca.nat.gov.tw/download/GCA_SSL_Baseline_Requirements_Audit_Report.pdf

Government Certification Authority is responsible for issuing SSL certificate to Taiwan’s government website.

Acceding to the Baseline Requirements of CA/Browser forum, we add the description about commitment to comply with the CA/Browser Forum Baseline Requirements in GCA’s CPS. (Chapter 1.1P.10)
http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.8.pdf

We also add the SSL verification procedures in this CPS(Chapter 3.1.12 P.36、Chapter4.2.3P.43). 
We also add the email address verification procedures in this CPS(Chapter 3.1.11 P.35-36、Chapter4.1P.40、Chapter4.2.1P.41)

We didn’t issue Code Signing certificate.

Comment 8

[Kathleen Wilson]

I am working on importing the data for this request into Salesforce, and updating the data based on Comment #7.

In the meantime, please send me email with the Primary Point of Contact information listed here:
https://wiki.mozilla.org/CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29

Comment 9

[Kathleen Wilson]

Is http://grca.nat.gov.tw/01-06.html the current document repository?

Comment 10

[Kathleen Wilson]

Attachment: 1065896-CAInformation.pdf

I have entered the data for this request into Salesforce. Please review the attached document, and comment in this bug to provide corrections and updates, or to state the the data is correct and current.

Also, when audit statements are provided by the CA rather than being posted on the webtrust.org website, Mozilla's root inclusion process requires me to do an independent verification to confirm the authenticity of the audit statement. So, please send me the direct contact information for the people at KPMG who can confirm the authenticity of the audit statements listed above.

Comment 11

[National Development Council]

(In reply to Kathleen Wilson from comment #8)
> I am working on importing the data for this request into Salesforce, and
> updating the data based on Comment #7.
> 
> In the meantime, please send me email with the Primary Point of Contact
> information listed here:
> https://wiki.mozilla.org/CA:
> Information_checklist#CA_Primary_Point_of_Contact_.28POC.29

Our Offical Email: [e-mail] 
POC: [e-mail]     Hung-Yu Hsu (Mr.)contractor

Comment 12

[National Development Council]

(In reply to Kathleen Wilson from comment #9)
> Is http://grca.nat.gov.tw/01-06.html the current document repository?

Yes, we put the latest document here.(Chinese)
Our CAs only provide services in our country so that the most documents are made in Chinese.
We only translated our CP and CPS into English and we did not put them on this repository.
Your can get the GRCA CP and CPS from the URL below:
GRCA CP: http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.7.pdf        
GRCA CPS: http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.4.pdf
If you need any other documents or any help, please let me know.

Comment 13

[National Development Council]

(In reply to Kathleen Wilson from comment #10)
> Created attachment 8704770 [details]
> 1065896-CAInformation.pdf
> 
> I have entered the data for this request into Salesforce. Please review the
> attached document, and comment in this bug to provide corrections and
> updates, or to state the the data is correct and current.
> 
> Also, when audit statements are provided by the CA rather than being posted
> on the webtrust.org website, Mozilla's root inclusion process requires me to
> do an independent verification to confirm the authenticity of the audit
> statement. So, please send me the direct contact information for the people
> at KPMG who can confirm the authenticity of the audit statements listed
> above.

The data is correct except the URL of our CP and CPS.
Updating:
GPKI CP:
http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.7.pdf

GRCA CPS:
http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.4.pdf

GCA CPS(intermediate that can issue SSL certs): http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.8.pdf

The contact information for the people at KPMG is below:
David Hsiu
68F, TAIPEI 101 TOWER, No.7, Sec. 5, Xinyi Road,
Taipei 11049, Taiwan (R.O.C.)
email: [e-mail]
T: [phone] ext.11900 
F: [phone] ext.11900

Comment 14

[Kathleen Wilson]

I have exchanged email with the auditor at KPMG to confirm the authenticity of the audit statements.

Comment 15

[Kathleen Wilson]

Attachment: 1065896-CAInformation.pdf

Comment 16

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 17

[Kathleen Wilson]

We recently added two tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
 ERROR: CA certificates must include commonName in subject 

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://gcaweb.nat.gov.tw/GCAEE/GCAPriApply/GCAPriApply.html'

Using certificate from local file 'GRCA2.cert'

    /C=TW/O=\xE8\xA1\x8C\xE6\x94\xBF\xE9\x99\xA2/OU=\xE5\x9C\x8B\xE5\xAE\xB6\xE7\x99\xBC\xE5\xB1\x95\xE5\xA7\x94\xE5\x93\xA1\xE6\x9C\x83/CN=gcaweb.nat.gov.tw/serialNumber=0000000010020259
        Informational
            TLS Server certificate identified
        Error
            BR certificates with organizationName must include either localityName or stateOrProvinceName

    /C=TW/O=\xE8\xA1\x8C\xE6\x94\xBF\xE9\x99\xA2/OU=\xE6\x94\xBF\xE5\xBA\x9C\xE6\x86\x91\xE8\xAD\x89\xE7\xAE\xA1\xE7\x90\x86\xE4\xB8\xAD\xE5\xBF\x83
        Informational
            CA certificate identified
        Error
            CA certificates must include commonName in subject
~~

Please add a comment in this bug when the errors have been resolved.

Comment 18

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #17)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

Comment 19

[National Development Council]

reply comment 17

About the Error2:
「BR certificates with organizationName must include either localityName or stateOrProvinceName」
Ans: Please test the following certificates which include either localityName or stateOrProvinceName.
https://www.ilepb.gov.tw (Certificate Serial No. :B9AB99090F7BB069B5569E589D848BE1)
https://eform.taichung.gov.tw (Certificate Serial No. :751BC6B07782F3FB5856DCFF57B5CE6C)
https://cabu3.kcg.gov.tw (Certificate Serial No. :2141567435AF46B5C2568F6A61AC840E)
https://taoyuanhulk.tycg.gov.tw (Certificate Serial No. :AD22F13CD4CD504063563DA5614BFE4A)
https://job.gov.taipei (Certificate Serial No. :4F1F4FF6522587097D54F682ED1530A9)
https://temple.minjeng.ntpc.gov.tw (Certificate Serial No. :765F5EE2B0A257DA0A563E204180EEFD)
https://online.chcg.gov.tw (Certificate Serial No. :3976B7F4CB4F8CAB9B5672E552BD151F)

About the Error1:
「CA certificates must include commonName in subject」
Ans: Actually, we don’t find this requirement in BR. As far as I know, this requirement is by Microsoft last year(June,2015). Is it necessary? Or maybe it should not be retrospective?

B.R-->
7.1.2.1Root CA Certificate .
 e. Subject Information
The Certificate Subject MUST contain the following:
‐ countryName (OID 2.5.4.6). This field MUST contain the two‐letter ISO 3166‐1 country code for the
country in which the CA’s place of business is located.
‐ organizationName (OID 2.5.4.10). This field MUST contain the name (or abbreviation thereof),
trademark, or other meaningful identifier for the CA, provided that they accurately identify the CA.
The field MUST NOT contain exclusively a generic designation such as “Root 1”.

Comment 20

[Kathleen Wilson]

(In reply to National Development Council from comment #19)
> reply comment 17
> 
> About the Error2:
> 「BR certificates with organizationName must include either localityName or
> stateOrProvinceName」
> Ans: Please test the following certificates which include either
> localityName or stateOrProvinceName.
> https://www.ilepb.gov.tw (Certificate Serial No.
> :B9AB99090F7BB069B5569E589D848BE1)
> https://eform.taichung.gov.tw (Certificate Serial No.
> :751BC6B07782F3FB5856DCFF57B5CE6C)
> https://cabu3.kcg.gov.tw (Certificate Serial No.
> :2141567435AF46B5C2568F6A61AC840E)
> https://taoyuanhulk.tycg.gov.tw (Certificate Serial No.
> :AD22F13CD4CD504063563DA5614BFE4A)
> https://job.gov.taipei (Certificate Serial No.
> :4F1F4FF6522587097D54F682ED1530A9)
> https://temple.minjeng.ntpc.gov.tw (Certificate Serial No.
> :765F5EE2B0A257DA0A563E204180EEFD)
> https://online.chcg.gov.tw (Certificate Serial No.
> :3976B7F4CB4F8CAB9B5672E552BD151F)
> 

Are you planning on fixing the SSL cert for the previously given site?
https://gcaweb.nat.gov.tw/GCAEE/GCAPriApply/GCAPriApply.html
I think the idea of the certlint tool is to identify if the CA is issuing BR-compliant certs. So, please clarify your plan in this regards.

> About the Error1:
> 「CA certificates must include commonName in subject」
> Ans: Actually, we don’t find this requirement in BR. As far as I know, this
> requirement is by Microsoft last year(June,2015). Is it necessary? Or maybe
> it should not be retrospective?
> 
> B.R-->
> 7.1.2.1Root CA Certificate .
>  e. Subject Information
> The Certificate Subject MUST contain the following:
> ‐ countryName (OID 2.5.4.6). This field MUST contain the two‐letter ISO
> 3166‐1 country code for the
> country in which the CA’s place of business is located.
> ‐ organizationName (OID 2.5.4.10). This field MUST contain the name (or
> abbreviation thereof),
> trademark, or other meaningful identifier for the CA, provided that they
> accurately identify the CA.
> The field MUST NOT contain exclusively a generic designation such as “Root
> 1”.

You are correct. The certlint tool will be updated to make this a notice rather than an error. Thank you for pointing this out.

Comment 21

[Li-Chun CHEN]

About the Error2:「BR certificates with organizationName must include either localityName or
stateOrProvinceName」, there is a discusion in https://bugzilla.cabforum.org/show_bug.cgi?id=2. Also, there is a discussion in CP working group and F2F meeting. I think BR will be modified, maybe B.R. 7.1.4.2.2 d/e as below: 

d.    Certificate Field: subject:localityName (OID: 2.5.4.7) 
Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.
Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the
subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the
subject:countryName field has a centralized registry for that kind of organizations so that the
organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.
Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.
 
e.    Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) 
Required if the subject:organizationName field is present and subject:localityName field is absent.
Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the
subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the
subject:countryName field has a centralized registry for that kind of organizations so that the
organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.
Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.

Comment 22

[Kathleen Wilson]

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

Thank you for the clarification, and for following up with the appropriate groups to correctly resolve this. In the meantime, I think it is fine to proceed with this request.

As per Comment #16, this request is in the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 23

[National Development Council]

Dear Kathleen

This request has been added to the queue for public discussion for a while.
It is very urgent for Taiwan to put our root certificate in Mozilla's products. 

Could you please help us?
Is there anything we should do or any problem we have not resolved?  

Or maybe you can tell me, when we can start this discussion.

Comment 24

[Kathleen Wilson]

I am now opening the public discussion period for this request from the Government of Taiwan to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits.

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Taiwan GRCA Root Renewal Request".

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

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

Comment 25

[Kathleen Wilson]

Attachment: MozillaTest.pdf

Comment 26

[National Development Council]

Attachment: GPKI Audit_Supplement_2017.pdf

Comment 27

[Kathleen Wilson]

The discussion of this request is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/eFG27ZTYWD8/WleX5FSHEQAJ

The status of the discussion is that I am waiting for a member of the community to do a thorough review of the CA's CP/CPS documents.
https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

The problem is that the people who have been doing these reviews are too busy right now to do them. We are looking into ways to solve this problem, including the addition of having CAs do their own self-assessment according to the BRs.
We are planning to add this BR-self-assessment step to Mozilla's root inclusion/update request, and discussion about it has started here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

A draft 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

Note:
Current version of the BRs: 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
For section 3.2.2.4 (Domain validation), use:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

That comparison is basically what the member of the community would do in regards to the thorough review of the CP/CPS. Therefore, if the CA provides the evaluation, it will make the job much easier for a member of the community to confirm their findings.

Therefore, in order to get this request moving forward again, please preform the BR-Self-Assessment, attach your BR-self-assessment to this bug, and post a comment in the discussion when the self-assessment has been completed.

Comment 28

[Kan-Ru Chen [:kanru] (UTC+9)]

Hi Kathleen and Aaron, is it possible we move this forward faster? See the linked bug 1361231, it looks like this new root has been rolled out to production. It means all user of Firefox in Taiwan can't access all government websites securely or even impossible. The error is SEC_ERROR_BAD_SIGNATURE so it's not even possible to add exceptions. This month is tax season so this is really bad.

A related question is if we add this new root in Nightly, how do we push it to released version?

Comment 29

[Aaron Wu]

Hi Kan-Ru,

Thank you to address this concern in this bug, current status of this request is that we are waiting for CA's response for BR Self Assessment in Comment#27.

You can see the last comment in public discussion for Taiwan GRCA Root Renewal Request[1], this request almost approach to final stage and be approved. Before that, CA needs to perform the BR-Self Assessment (template[2]), attach BR-Self-Assessment to this bug, and post a comment in the discussion when the self-assessment has been completed. Then we can quickly move forward.

Thanks for understanding! 

[1] http://bit.ly/2p68pCJ
[2] https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing


Kind regards,
Aaron

Comment 30

[National Development Council]

Attachment: TW GPKI SSL B.R self-assessment

provide the TW GPKI SSL B.R self-assessment and relevant documents.

Comment 31

[Aaron Wu]

Attachment: CAInformation_TaiwanGRCA_Complete_20170525.pdf

Comment 32

[Aaron Wu]

Hi,

I've verified your BR Self Assessment, and updated in Salesforce as well. 

Here is Summary of Information Gathered as Comment#31.

Thanks,
Aaron

Comment 33

[Aaron Wu]

Hi Mr. Hsu,

There are two things still need your update and input before
moving to next stage:

1. As checked your responses to the April 2017 CA Communication.
https://wiki.mozilla.org/CA/Communications#April_2017_Responses
For the date by which you will update your CP/CPS in regards to domain
validation procedures is July 20, 2017.

And In practice, certificates issued by GRCA and GCA after each
Effective Date are in compliance with the item in the table.. However,
most of them are not described in the current CP and CPS. They will
add in next version of GRCA CPS and GCA CPS, expected to be completed
before December 31, 2017."  I noticed the dates of your CP/CPS
documents are *too* old.

2. Since your root requests Website trust bit, please provide the 3
URLs to the test websites as described in Section 2.2 of the BRs: 
"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

Quickly summarize below
1) Provide updated CP/CPS documents that address the April 2017 CA
Communication and resolve all items in the BR Self Assessment.
2) Provide the 3 test websites (valid, revoked, expired).

Thank you for your cooperation!

Kind regards,
Aaron

Comment 34

[Aaron Wu]

Here is the update from Mr. Hsu via email:

"Here are the test URLs

1. valid  https://gca.nat.gov.tw
2. revoked  https://oid.nat.gov.tw
3. expired  https://gtestca.nat.gov.tw

We are working to revise our CP and CPS to meet all items in the BR Self Assessment.
We will finish it as soon as we can."

I've verified the test websites above, and updated them into Salesforce.

Regards,
Aaron

Comment 35

[National Development Council]

Attachment: (Updated)TW GPKI SSL B.R self-assessment.7z

updating the TW GPKI SSL B.R self-assessment and relevant documents.

Comment 36

[National Development Council]

Attachment: TW GPKI SSL B.R self-assessment.7z

Please treat this attachment as correct as there are mistakes in the contents of the previous one(8884716).

Comment 37

[David E. Ross]

All comments in this bug report on behalf of the requester have been from "National Development Council", an organization.  Is this appropriate?  Or should there be a live human as the point-of-contact?

Comment 38

[Kathleen Wilson]

(In reply to David E. Ross from comment #37)
> All comments in this bug report on behalf of the requester have been from
> "National Development Council", an organization.  Is this appropriate?  Or
> should there be a live human as the point-of-contact?

In the Common CA Database we have contact information for the Primary Points of Contact at their @cht.com.tw email addresses, and I do exchange email directly with them. I am OK with them using this other email address in Bugzilla.

Comment 39

[National Development Council]

Attachment: (Updated)TW GPKI SSL B.R self-assessment.7z

updated the TW GPKI SSL B.R self-assessment. 

In the former version of SSL B.R self-assessment, the contents of BR Section 1.2.1 and 1.2.2 are upside down. Therefore, we updated the corrected version. Except for the contents of BR Section 1.2.1 and 1.2.2, the rest of the SSL B.R self-assessment remained unchanged.

Comment 40

[Aaron Wu]

(In reply to National Development Council from comment #39)
> Created attachment 8888237 [details]
> (Updated)TW GPKI SSL B.R self-assessment.7z
> 
> updated the TW GPKI SSL B.R self-assessment. 

Noted with thanks.

> 
> In the former version of SSL B.R self-assessment, the contents of BR Section
> 1.2.1 and 1.2.2 are upside down. Therefore, we updated the corrected
> version. Except for the contents of BR Section 1.2.1 and 1.2.2, the rest of
> the SSL B.R self-assessment remained unchanged.

I am verifying the BR Self Assessment v1.1, and found that there are many sessions in v1.1 which different from the previous version v1.0

- session 2.2: you added GCA CPS 4.1
- session 2.3: you updated the GPKI CP and GRCA/GCA CPS 8.1 and make some change of the explain field
- session 3.2.2.5: you update the GCA CPS 3.1.12 and make change of the explain field
- session 3.2.2.6: you update the GCA CPS 3.1.12 and make change of the explain field
- session 3.2.2.7: you update the GCA CPS 3.1.12 and make change of the explain field
..etc

As you mentioned the rest of updated BR Self Assessment remain unchanged except 1.2.1 and 1.2.2, could you please confirm v1.1 is the final one?

Thanks,
Aaron

Comment 41

[National Development Council]

(In reply to Aaron Wu from comment #40)
> (In reply to National Development Council from comment #39)
> > Created attachment 8888237 [details]
> > (Updated)TW GPKI SSL B.R self-assessment.7z
> > 
> > updated the TW GPKI SSL B.R self-assessment. 
> 
> Noted with thanks.
> 
> > 
> > In the former version of SSL B.R self-assessment, the contents of BR Section
> > 1.2.1 and 1.2.2 are upside down. Therefore, we updated the corrected
> > version. Except for the contents of BR Section 1.2.1 and 1.2.2, the rest of
> > the SSL B.R self-assessment remained unchanged.
> 
> I am verifying the BR Self Assessment v1.1, and found that there are many
> sessions in v1.1 which different from the previous version v1.0
> 
> - session 2.2: you added GCA CPS 4.1
> - session 2.3: you updated the GPKI CP and GRCA/GCA CPS 8.1 and make some
> change of the explain field
> - session 3.2.2.5: you update the GCA CPS 3.1.12 and make change of the
> explain field
> - session 3.2.2.6: you update the GCA CPS 3.1.12 and make change of the
> explain field
> - session 3.2.2.7: you update the GCA CPS 3.1.12 and make change of the
> explain field
> ..etc
> 
> As you mentioned the rest of updated BR Self Assessment remain unchanged
> except 1.2.1 and 1.2.2, could you please confirm v1.1 is the final one?
> 
> Thanks,
> Aaron

Yes, the BR Self Assessment v1.1 is the final one.

Comment 42

[National Development Council]

(In reply to National Development Council from comment #41)
> (In reply to Aaron Wu from comment #40)
> > (In reply to National Development Council from comment #39)
> > > Created attachment 8888237 [details]
> > > (Updated)TW GPKI SSL B.R self-assessment.7z
> > > 
> > > updated the TW GPKI SSL B.R self-assessment. 
> > 
> > Noted with thanks.
> > 
> > > 
> > > In the former version of SSL B.R self-assessment, the contents of BR Section
> > > 1.2.1 and 1.2.2 are upside down. Therefore, we updated the corrected
> > > version. Except for the contents of BR Section 1.2.1 and 1.2.2, the rest of
> > > the SSL B.R self-assessment remained unchanged.
> > 
> > I am verifying the BR Self Assessment v1.1, and found that there are many
> > sessions in v1.1 which different from the previous version v1.0
> > 
> > - session 2.2: you added GCA CPS 4.1
> > - session 2.3: you updated the GPKI CP and GRCA/GCA CPS 8.1 and make some
> > change of the explain field
> > - session 3.2.2.5: you update the GCA CPS 3.1.12 and make change of the
> > explain field
> > - session 3.2.2.6: you update the GCA CPS 3.1.12 and make change of the
> > explain field
> > - session 3.2.2.7: you update the GCA CPS 3.1.12 and make change of the
> > explain field
> > ..etc
> > 
> > As you mentioned the rest of updated BR Self Assessment remain unchanged
> > except 1.2.1 and 1.2.2, could you please confirm v1.1 is the final one?
> > 
> > Thanks,
> > Aaron
> 
> Yes, the BR Self Assessment v1.1 is the final one.

SOrry, I make a mistake.
The final version is the v1.2.(Attachment 8888237 [details])

Comment 43

[Aaron Wu]

Hi,

I've verified BR Self Assessment v1.2, thanks for your update. 

All audit statement info have also verified as well, and make them updated in Salesforce. 

Kind regards,
Aaron

Comment 44

[Aaron Wu]

Hi,

Once re-verifying your updated CP/CPS, they can not access now. Could you please double check? And make sure these documents are up-to-date version.

GPKI CP: 
http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.9.pdf

GRCA (Root) CPS:       
http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.5.pdf

GCA CPS(intermediate that can issue SSL certs):       http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.9.pdf


Thanks,
Aaron

Comment 45

[National Development Council]

I have checked and fixed them.
Please try again.

GPKI CP: 
http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.9.pdf

GRCA (Root) CPS:       
http://grca.nat.gov.tw/download/GRCA_CPS_eng_v1.5.pdf

GCA CPS(intermediate that can issue SSL certs):       http://gca.nat.gov.tw/download/Government_Certification_Authority_Certification_Practice_Statement_V1.9.pdf

Comment 46

[Aaron Wu]

Thanks to fix them!

By the way, would you upload these up-to-date CP/CPS documents onto GRCA repository?

http://grca.nat.gov.tw/GRCAeng/3-1.html


Kind Regards,
Aaron

Comment 47

[National Development Council]

Thanks for your friendly reminder.

we just updated our repository.

http://grca.nat.gov.tw/GRCAeng/3-1.html

Comment 48

[Kathleen Wilson]

Before we can move any further with this request, we need to ensure that the full CA Hierarchy is understood, and properly audited.

Here's what I think the subCAs are: MOICA, MOEACA, GCA, XCA, HCA

It appears that this CA is a Super-CA, as described here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

So, either this CA needs to provide the required audits for all of their subCAs annually, or they should not be directly included in Mozilla's root store. Instead, the subCAs may apply directly for inclusion in Mozilla's program.

Comment 49

[National Development Council]

Provide the latest Audit reports for all subCAs .

GRCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2017.pdf)
GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2017.pdf)
GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2017.pdf)
XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Audit_Report_2017.pdf)
HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2016.pdf)
HCA BR (http://grca.nat.gov.tw/download/Audit/HCA_BR_Audit_Report_2016.pdf)
MOEACA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2017.pdf)
MOICA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2017.pdf)

The annual audit for HCA just finished. we don't get the audit report yet.

Comment 50

[Ryan Sleevi]

re: Comment 49:

Can you indicate why GRCA, GCA, XCA, MOEACA, and MOICA do not have WebTrust BR audits?

Comment 51

[National Development Council]

GRCA has 5 subordinate CAs, including GCA, XCA, MOICA, MOEACA and HCA. Only GCA and HCA (HCA no longer issues SSL certificate since Sep. 2016) issue SSL certificates, and we have baseline requirement audit reports for both GCA and HCA. 

The baseline requirement audit also applied to GRCA. Since GRCA does not issues any SSL certificates, we don’t have a separated audit report for it. Instead of providing the audit report, we provide an audit statement that states how the baseline requirement audits are performed according to Kathleen’s suggestion(https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/eFG27ZTYWD8/WleX5FSHEQAJ  16/12/14). The audit statement is available at https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815(2016’s version. The 2017’s will be available in Nov. 2017). 
The auditors, KPMG are willing to explain the audit process if necessary. The contact information for the people at KPMG is below:
David Hsiu
68F, TAIPEI 101 TOWER, No.7, Sec. 5, Xinyi Road,
Taipei 11049, Taiwan (R.O.C.)
email: [e-mail]
T: [phone] ext.11900 
F: [phone] ext.11900

Comment 52

[Wayne Thayer]

We need the following information to proceed with this request:

1. The 2017 audit statement confirming that the XCM, MOICA, and MOECA subordinate CAs have not issued SSL certificates in the most recent audit period. This would possibly allow us to accept the root by adding these subordinate CAs to OneCRL instead of requiring them to be BR audited.

2. A 2017 BR audit statement for the GRCA root. The auditors have attested in a separate statement that the GRCA root has been BR audited, but there should be a BR audit statement covering the root. Mozilla policy section 3.1.4 requires that audit reports list each certificate covered by the audit.

3. The 2017 audit reports for the HCA subordinate CA.

Comment 53

[National Development Council]

(In reply to Wayne Thayer (UTC-7) from comment #52)
> We need the following information to proceed with this request:
> 
> 1. The 2017 audit statement confirming that the XCM, MOICA, and MOECA
> subordinate CAs have not issued SSL certificates in the most recent audit
> period. This would possibly allow us to accept the root by adding these
> subordinate CAs to OneCRL instead of requiring them to be BR audited.
-->That's OK.


> 2. A 2017 BR audit statement for the GRCA root. The auditors have attested
> in a separate statement that the GRCA root has been BR audited, but there
> should be a BR audit statement covering the root. Mozilla policy section
> 3.1.4 requires that audit reports list each certificate covered by the audit.
-->Please see GPKI audit statement 2017(http://grca.nat.gov.tw/download/Audit/GPKI_Audit_Supplement_2017.pdf)

> 3. The 2017 audit reports for the HCA subordinate CA.
-->I have updated HCA audit reports to CCADB. 
HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2017.pdf)
HCA BR (http://grca.nat.gov.tw/download/Audit/HCA_BR_Audit_Report_2017.pdf)

Comment 54

[National Development Council]

Attachment: GPKI_Audit_Supplement_2017.pdf

Comment 55

[Wayne Thayer]

I still have the following concerns about these audit reports:

1. We need to confirm the authenticity of the new 2017 HCA reports. Aaron (added here as needinfo), can you do this?
2. There are no audit reports for the GRCA root - only the summary "GPKI Audit Supplement". The GRCA root should be explicitly included in audit reports.
3. The new audit reports do not contain the information required by Mozilla policy section 3.1.4
4. Neither of the HCA audit reports includes the "Issue related to OCSP responder transition" noted in the latest supplement.

Comment 56

[National Development Council]

(In reply to Wayne Thayer [:wayne] from comment #55)
> I still have the following concerns about these audit reports:
> 

> 2. There are no audit reports for the GRCA root - only the summary "GPKI
> Audit Supplement". The GRCA root should be explicitly included in audit
> reports.
-->Next year, we will provide the baseline requirement audit report for GRCA.
But the baseline requirement audit also applied to GRCA this year. Our consideration is since GRCA does not issue any SSL certificates, we don’t have a separated audit report for it. Instead of providing the audit report, we provide an audit supplement that states how the baseline requirement audits are performed according to Kathleen’s suggestion. The audit statement is available at http://grca.nat.gov.tw/download/Audit/GPKI_Audit_Supplement_2017.pdf


> 1. We need to confirm the authenticity of the new 2017 HCA reports. Aaron
> (added here as needinfo), can you do this?
> 3. The new audit reports do not contain the information required by Mozilla
> policy section 3.1.4
> 4. Neither of the HCA audit reports includes the "Issue related to OCSP
> responder transition" noted in the latest supplement.

-->About Q1, Q3 and Q4, I will ask our auditors, KPMG to explain.
The contact information for the people at KPMG is below:
David Hsiu
68F, TAIPEI 101 TOWER, No.7, Sec. 5, Xinyi Road,
Taipei 11049, Taiwan (R.O.C.)
email: [e-mail]
T: [phone] ext.11900 
F: [phone] ext.11900

Comment 57

[Aaron Wu]

(In reply to Wayne Thayer [:wayne] from comment #55)
> I still have the following concerns about these audit reports:
> 
> 1. We need to confirm the authenticity of the new 2017 HCA reports. Aaron
> (added here as needinfo), can you do this?

Sure, I am confirming authenticity with KPMG.

> 2. There are no audit reports for the GRCA root - only the summary "GPKI
> Audit Supplement". The GRCA root should be explicitly included in audit
> reports.
> 3. The new audit reports do not contain the information required by Mozilla
> policy section 3.1.4
> 4. Neither of the HCA audit reports includes the "Issue related to OCSP
> responder transition" noted in the latest supplement.

Comment 58

[Wayne Thayer]

We received an email from David Hsiu of KPMG confirming the authenticity of the 2017 audit reports. With that, I believe we have all the necessary information and can move this request back into the public discussion phase.

I will recommend that the XCA, MOICA, and MOEACA sub-CAs be added to OneCRL because they are neither technically constrained or BR audited.

Comment 59

[Kathleen Wilson]

Attachment: 1065896-CA-Information-Final.pdf

Comment 60

[Wayne Thayer]

Completed the CPS review and posted the following to the mozilla.dev.security.policy thread:

==Good==
1. GRCA has requested that this root be constrained to issuing certificates for .tw domains.
2. The BR Self Assessment is very complete.

==Meh==
1. This root is intended to replace an older root that has the exact same DN. Compatibility concerns were raised but testing performed by GRCA found no problems.
2. The CP doesn’t contain the ’dated changelog’ required under Mozilla policy section 3.3.
3. The audit reports don’t include the version numbers of CA policy documents referenced during the audit.
4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs covered by the audit. They are listed in a supplemental statement provided by the auditor.
5. The CP/CPS docs are still in RFC 2527 format.
6. It is not clear how the policy for authenticating individual identity described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3 and 3.2.5. Please provide more detail.
7. In September it was reported that GRCA was signing OCSP responses with an unconstrained SHA-1 certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been fixed.
8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for validating email addresses are not specified in any documents.

==Bad==
1. The application for inclusion states that only the GCA subordinate can issue SSL certificates, and this subordinate has its own CPS that lists SSL-specific policies such as CAA. The HCA subordinate also has a BR audit, but GRCA has stated that it is no longer used to issue SSL certificates. Should the HCA subordinate be added to OneCRL along with the other subordinates (XCA, MOICA, and MOECACA) that are not BR audited?
2. According to the audit supplement, the MOICA audit report is qualified due to ‘one issue related to system access management’, but the actual audit report is not written in English. Please describe the issue and how it was resolved.
3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are not listed as required by BR section 2.2.
4. GCA CPS section 3.1.12 describes the domain authorization process for SSL certificates, but it does not comply with Mozilla policy section 2.2(3).

Comment 61

[Wayne Thayer]

It was pointed out in a discussion on the mozilla.dev.security.policy forum (https://groups.google.com/d/msg/mozilla.dev.security.policy/eFG27ZTYWD8/zktCdEWyAAAJ) that simply adding the XCA, MOICA, and MOECACA subordinate CAs to OneCRL does not comply with Mozilla policy. The correct way to handle this issue is to change this request from inclusion of the root to inclusion of the subordinate CAs that fully comply with Mozilla policies. Please refer to bug 1226100 for another example of this.

Please decide which subordinate CAs you would like to have included in the Mozilla root store. For each of those, please provide the information listed here: https://wiki.mozilla.org/CA:Information_checklist (treating each of them as a " root certificate" for the purpose of our process)

I am placing this request on-hold pending the receipt of this information.

Comment 62

[National Development Council]

(In reply to Wayne Thayer [:wayne] from comment #60)
> Completed the CPS review and posted the following to the
> mozilla.dev.security.policy thread:
> 
> ==Good==
> 1. GRCA has requested that this root be constrained to issuing certificates
> for .tw domains.
> 2. The BR Self Assessment is very complete.
> 
> ==Meh==
> 1. This root is intended to replace an older root that has the exact same
> DN. Compatibility concerns were raised but testing performed by GRCA found
> no problems.
> 2. The CP doesn’t contain the ’dated changelog’ required under Mozilla
> policy section 3.3.
The ‘dated changelog’ will be added to RFC 3647 version’s CP.

> 3. The audit reports don’t include the version numbers of CA policy
> documents referenced during the audit.
The CPS version information will be included in next audit report.

> 4. The WebTrust for CAs audit report doesn’t list all the subordinate CAs
> covered by the audit. They are listed in a supplemental statement provided
> by the auditor.
> 5. The CP/CPS docs are still in RFC 2527 format.
The GPKI CP, GRCA CPS and GCA CPS will have RFC 3647 version before 2018/5/31.

> 6. It is not clear how the policy for authenticating individual identity
> described in section 3.1.9 of the GCA CPS meets the requirements of BR 3.2.3
> and 3.2.5. Please provide more detail.
The GCA SSL certificates are only issued to government agency websites. The government agency must apply certificate through official document. Our government use GCA smartcards to sign official document electronically. The official document must be signed by representative (such as minister) of the government agency, and are also signed by the government agency’s smartcard. 
After receiving official document, the registration authority verifies electronically signed official document and validates the applicant’s identity through government directory tree to ensure the existence of the government agency.


> 7. In September it was reported that GRCA was signing OCSP responses with an
> unconstrained SHA-1 certificate:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 The issue has been
> fixed.
> 8. Procedures that fulfill Mozilla policy section 2.2(2) requirements for
> validating email addresses are not specified in any documents.
The statements of validating email address are listed below:
GCA -> 3.1.11
HCA -> 3.1.11 (not allowed)
MOICA -> 3.1.9.2
MOEACA -> 3.1.11
XCA -> 3.1.9

> ==Bad==
> 1. The application for inclusion states that only the GCA subordinate can
> issue SSL certificates, and this subordinate has its own CPS that lists
> SSL-specific policies such as CAA. The HCA subordinate also has a BR audit,
> but GRCA has stated that it is no longer used to issue SSL certificates.
> Should the HCA subordinate be added to OneCRL along with the other
> subordinates (XCA, MOICA, and MOECACA) that are not BR audited?
HCA will revoke all SSL certificate by 2018/3/31. HCA may be put in OneCRL hence after.

> 2. According to the audit supplement, the MOICA audit report is qualified
> due to ‘one issue related to system access management’, but the actual audit
> report is not written in English. Please describe the issue and how it was
> resolved.
The auditor will provide translated audit supplement.

> 3. The GCA CPS describes CAA policies, but GRCA’s issuer domain names are
> not listed as required by BR section 2.2.
GRCA’s issuer domain are listed as grca.gov.tw.

> 4. GCA CPS section 3.1.12 describes the domain authorization process for SSL
> certificates, but it does not comply with Mozilla policy section 2.2(3).
GCA SSL certificates are issued only to government agencies. The IP and domain name are also managed by the same government agency as GCA. The government domain name registry center provide domain name registrar query service(https://rs.gsn.gov.tw). According to GCA CPS 3.1.12,RA will validate the domain name’s existence and validate the domain name’s owner is identical to the applicant. The RA will also contact domain name registrar to verify the applicant’s control of the domain.

Comment 63

[National Development Council]

Attachment: GCA Information.docx

Comment 64

[National Development Council]

Attachment: GCA Information V1.1.docx

Comment 65

[National Development Council]

(In reply to Wayne Thayer [:wayne] from comment #61)
> It was pointed out in a discussion on the mozilla.dev.security.policy forum
> (https://groups.google.com/d/msg/mozilla.dev.security.policy/eFG27ZTYWD8/
> zktCdEWyAAAJ) that simply adding the XCA, MOICA, and MOECACA subordinate CAs
> to OneCRL does not comply with Mozilla policy. The correct way to handle
> this issue is to change this request from inclusion of the root to inclusion
> of the subordinate CAs that fully comply with Mozilla policies. Please refer
> to bug 1226100 for another example of this.
> 
> Please decide which subordinate CAs you would like to have included in the
> Mozilla root store. For each of those, please provide the information listed
> here: https://wiki.mozilla.org/CA:Information_checklist (treating each of
> them as a " root certificate" for the purpose of our process)
> 
> I am placing this request on-hold pending the receipt of this information.

There are some questions listed below:
1.According to the suggestion, put only GCA (subordinate CA) into Mozilla’s trust list is the choice we want. May we use this thread to finish the inclusion process? Any things else we should do? Here is the information about GCA.(https://bugzilla.mozilla.org/attachment.cgi?id=8961656)
2.In the future, we still hopes that the whole GRCA(root CA) is included in Mozilla’s trust list. We will try to make every CA comply to Mozilla’s policy and BRs. If it is done, shall we use the thread to apply the inclusion, or we should start a new one?

Comment 66

[Wayne Thayer]

(In reply to National Development Council from comment #65)
> (In reply to Wayne Thayer [:wayne] from comment #61)
> There are some questions listed below:
> 1.According to the suggestion, put only GCA (subordinate CA) into Mozilla’s
> trust list is the choice we want. May we use this thread to finish the
> inclusion process? Any things else we should do? Here is the information
> about GCA.(https://bugzilla.mozilla.org/attachment.cgi?id=8961656)

Please submit a new bug for the GCA only inclusion request.

> 2.In the future, we still hopes that the whole GRCA(root CA) is included in
> Mozilla’s trust list. We will try to make every CA comply to Mozilla’s
> policy and BRs. If it is done, shall we use the thread to apply the
> inclusion, or we should start a new one?

You may use this bug to restart the inclusion request for the root.

Comment 67

[Kathleen Wilson]

I am closing old requests that are for inclusion of super-CA root certificates.

This CA may re-apply for inclusion of their root certificate when they meet all of the requirements listed here:

https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

Until then, this CA's (first-level) subordinate CAs may apply for inclusion of their certificate as a trust anchor, as described here:

https://wiki.mozilla.org/CA/Application_Process