1845081 - Add MOIS SSL Root CA

Status: ASSIGNED

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

Description

[EUIYEOL CHOI]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.51

Steps to reproduce:

We, KLID (Korea Local Information Research & Development Institute), would like to include our new Root certificate (CN = MOIS SSL Root CA) into Mozilla Root Store.

Actual results:

Our Root certificate has been included in CCADB as the below.
CCADB Case No: 00001324
CA Owner/Certificate Name: Government of Korea, KLID
URL: https://ccadb.my.salesforce.com/5008Z00002BC4PiQAL

Expected results:

As a national Root CA, we would like to include our Root certificate into Mozilla Root Store for all users, regardless of browsers and OSs, to use our trusted services such as SSL/TLS certificates in the aim to ensure secure and reliable transactions provide by the government.

Comment 1

[Yongmin Hong [:revi]]

Point of order: what has changed since bug 1377389 comment 32 and bug 1451235?

Given Government of Korea's history of improper certificate issuance, I think this should be questioned.

It's also worth noting that 'MOIS' is the same organization behind bug 1377389 and this one. (Even the requesting organization is same.)

Comment 2

[EUIYEOL CHOI]

The Government of Korea, KLID, established a new SSL CA system and issued the root certificate in February 2023 in compliance with Mozilla Root Store Policy and CA Browser Forum Baseline Requirements. We also achieved the WebTrust seals for our SSL CA system and root certificate.

Comment 3

[EUIYEOL CHOI]

Attachment: Mozila_Quantifying_Value_MOIS.pdf

Hello Ben,
We have attached MOIS (Ministry of the Interior and Safety) resonse to the Mozila Quantifying Value.
Can you let us know if there are any other procedures we should follow?

Comment 4

[Ben Wilson]

From looking at your case in the CCADB, I noticed that you needed to file an "Add/Update Root Request" case to update some information in the records for this CA - see https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323. So, I helped you by opening Case #1720 (https://ccadb.my.site.com/500TO000003hBOPYA2). Even though I have your CPS in English and your self assessment, the CCADB is missing those URLs or the links don't quite work. Also, the URL to download your root CA certificate needs to be updated in the field "Root Certificate Download URL". (It currently is the URL for your CRL.) When you open Case #1720, go through the "POLICY DOCUMENTS" and "ROOT INFORMATION" tabs to make sure the information is up-to-date. You can skip the "CA OWNER", "AUDITS" and "TEST WEBSITES" tabs because that information looks current and complete. However, under "POLICY DOCUMENTS" click on "Add Policy Document" and fill in the required information (e.g. the URLs for your English CPs/CPSes), and be sure to click on the checkbox for the MOIS SSL Root CA and any other applicable root certificates at the bottom. Then, under the tab "ROOT INFORMATION", populate "Root Certificate Download URL" with the correct URL to download the root certificate from your website. Also, fix the URL for the download of your self-assessment (it looks like it is delivered over http instead of https).

When you're done inputting the information into Case #1720, be sure to click on "Submit to Root Store".

Meanwhile, I will queue up my review of your CPS and Self Assessment.

Comment 5

[EUIYEOL CHOI]

(In reply to Ben Wilson from comment #4)

From looking at your case in the CCADB, I noticed that you needed to file an "Add/Update Root Request" case to update some information in the records for this CA - see https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323. So, I helped you by opening Case #1720 (https://ccadb.my.site.com/500TO000003hBOPYA2). Even though I have your CPS in English and your self assessment, the CCADB is missing those URLs or the links don't quite work. Also, the URL to download your root CA certificate needs to be updated in the field "Root Certificate Download URL". (It currently is the URL for your CRL.) When you open Case #1720, go through the "POLICY DOCUMENTS" and "ROOT INFORMATION" tabs to make sure the information is up-to-date. You can skip the "CA OWNER", "AUDITS" and "TEST WEBSITES" tabs because that information looks current and complete. However, under "POLICY DOCUMENTS" click on "Add Policy Document" and fill in the required information (e.g. the URLs for your English CPs/CPSes), and be sure to click on the checkbox for the MOIS SSL Root CA and any other applicable root certificates at the bottom. Then, under the tab "ROOT INFORMATION", populate "Root Certificate Download URL" with the correct URL to download the root certificate from your website. Also, fix the URL for the download of your self-assessment (it looks like it is delivered over http instead of https).

When you're done inputting the information into Case #1720, be sure to click on "Submit to Root Store".

Meanwhile, I will queue up my review of your CPS and Self Assessment.

Thank you, Ben. We have added the required information and updated the thread in CCADB. You can find our English CPS. It would be appreciated if you could start reviewing the CPS. Feel free to let us know if you need any further assistance with our inclusion request.

Comment 6

[EUIYEOL CHOI]

(In reply to EUIYEOL CHOI from comment #5)

(In reply to Ben Wilson from comment #4)

From looking at your case in the CCADB, I noticed that you needed to file an "Add/Update Root Request" case to update some information in the records for this CA - see https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323. So, I helped you by opening Case #1720 (https://ccadb.my.site.com/500TO000003hBOPYA2). Even though I have your CPS in English and your self assessment, the CCADB is missing those URLs or the links don't quite work. Also, the URL to download your root CA certificate needs to be updated in the field "Root Certificate Download URL". (It currently is the URL for your CRL.) When you open Case #1720, go through the "POLICY DOCUMENTS" and "ROOT INFORMATION" tabs to make sure the information is up-to-date. You can skip the "CA OWNER", "AUDITS" and "TEST WEBSITES" tabs because that information looks current and complete. However, under "POLICY DOCUMENTS" click on "Add Policy Document" and fill in the required information (e.g. the URLs for your English CPs/CPSes), and be sure to click on the checkbox for the MOIS SSL Root CA and any other applicable root certificates at the bottom. Then, under the tab "ROOT INFORMATION", populate "Root Certificate Download URL" with the correct URL to download the root certificate from your website. Also, fix the URL for the download of your self-assessment (it looks like it is delivered over http instead of https).

When you're done inputting the information into Case #1720, be sure to click on "Submit to Root Store".

Meanwhile, I will queue up my review of your CPS and Self Assessment.

Thank you, Ben. We have added the required information and updated the thread in CCADB. You can find our English CPS. It would be appreciated if you could start reviewing the CPS. Feel free to let us know if you need any further assistance with our inclusion request.

We clicked on ‘Submit to Root Store’ in Case #1720 (https://ccadb.my.salesforce.com/500TO000003hBOPYA2), and the case status changed to ‘Closed’. We would appreciate it if you could inform us about the next steps.

Comment 7

[EUIYEOL CHOI]

Hello Ben,

We have updated our CPS into Case #1720. You can also find our CPS URL at the URL( https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323) We would like to appreciate if you could review the CPS.

Comment 8

[[e-mail]]

Hello Ben,

We have updated our CPS which is complied with CA Browser Forum Baseline Requirements and Network Security.
As you mentioned on the previous thread, we fixed the below information at the CCADB URL (https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323)

1. Root Certificate Download URL: you can download the Root certificate.
2. Self-Assessment (Link): it has been changed to https.

Comment 9

[Ben Wilson]

Here is the result of a quick review of your CPS.

Review of MOIS CPS v. 1.3, dated March 2024

General Issues

• Translation and Terminology: Ensure that the CPS is accurately translated into English with well-formed sentences and grammar. This will aid in readability.

Specific Issues and Recommendations

1. Introduction

• Statement of Adherence to BRs and Their Precedence:

• • Section 1.1

  • Observation: The current CP and CPS state, "the Certificate Authority issuing GSSL Certificate conforms to the current version of 'CA/Browser Forum (CABF) Baseline Requirement for the Issuance and Management of Publicly-Trusted Certificates' published by CA/Browser Forum at http://www.cabforum.org."

  • Issues:

  • • The Baseline Requirements have been re-titled to "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates."
    • Section 2.2 of the BRs requires that the CA state, "In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document."

  • Recommendation: Update the title to "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates" and include a statement: "In the event of any inconsistency between this document and the TLS Baseline Requirements, the TLS Baseline Requirements take precedence over this document."

• Problem Reporting Instructions:

• • Section 1.5.2
  • Observation: Needs clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud.
  • Recommendation: Include detailed instructions for reporting issues, specifying email addresses, URLs, and any forms required. Ensure compliance with section 4.9.3 of the CA/Browser Forum's TLS Baseline Requirements: "The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS."

3. Identification and Authentication

• Naming:

• • Section 3.1
  • Observation: The CPS should describe practices for handling Internationalized Domain Names (IDNs) in Korean.
  • Recommendation: Add explanation for handling Korean IDN domain names.

• Non-verified Subscriber Information:

• • Section 3.2.4
  • Observation: The CPS states, "A Certificate contains only validated information; optional subfields within the Subject field must contain the validated information or leave it empty."
  • Rating: Good

• Validation of Authority:

• • Section 3.2.5
  • Observation: Section 3.2.2.1 states, "For OV Certificate application, the GSSL CA validates the identity and address of the Applicant using documentation provided by, or communication with, at least one of the following: a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition; a third party database that is periodically updated and considered a Reliable Data Source; ..."
  • Rating: Good

• Validation of Domain Authorization or Control:

• • Section 3.2.2.4
  • Observation: MOIS should be aware of new requirements to conduct multi-perspective domain validation and CAA checks using MPIC (Multi-perspective Issuance Corroboration”).
  • Recommendation: Review and prepare for compliance with CA/Browser Forum Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives."

• Revocation Requests:

• • Sections 3.4, 4.9.2, and 4.9.12
  • Observation: The sections need to acknowledge that any third party with proof of key compromise can request revocation of a certificate.
  • Recommendation: Amend sections 3.4, 4.9.2, and 4.9.12 to acknowledge that any third party with proof of key compromise can request revocation. Specify the methods MOIS uses to receive notifications of key compromise in section 4.9.12.

4. Certificate Life-Cycle Operational Requirements

• Certificate Request Details:

• • Section 4.1.1
  • Observation: Currently states, "Certificate request must contain domain name to be included in Subject field of a Certificate."
  • Recommendation: Change to "Certificate requests must contain domain names to be included in the SubjectAlternativeName extension (SAN) of Certificates."
  • Rating: Needs to be fixed

• Revocation for Precertificates:

• • Section 4.3.1
  • Observation: MOIS should explain how revocation is possible for precertificates.
  • Recommendation: Explain how soon OCSP responses for new certificates are published and the process for revoking precertificates.

• Responding to Certificate Problem Reports (CPRs):

• • Section 4.9.5
  • Observation: "The GSSL CA investigates the facts and circumstances associated with the report and provides a preliminary report on its findings to the Subscriber or the entity that filed the problem report within 24 hours of receiving the Certificate Problem Report."
  • Rating: Good

• Methods to Demonstrate Private Key Compromise:

• • Section 4.9.12
  • Observation: See above.
  • Recommendation: See above.

5. Management, Operational, and Physical Controls

• Key Compromise Notification:

• • Section 5.7.3
  • Observation: CPS states, "In particular, once a Root CA private key is compromised, the GSSL CA informs browser vendors of the compromise and best estimate of the date of compromise."
  • Rating: Good

6. Technical Security Controls

• Network Security Controls:

• • Section 6.7
  • Observation: MOIS might want to amend this section by incorporating by reference the CA/B Forum's Network and Certificate Systems Security Requirements (NCSSRs), as amended by Ballot NS-003 and the upcoming Ballot NS-004.
  • Recommendation: Include references to the NCSSRs to ensure up-to-date compliance with network security controls.

7. Certificate Profiles

• Common Name in SAN:

• • Section 7.1.4.2
  • Observation: The CN must be one of the SANs that has been validated.
  • Recommendation: Explain how the CA ensures that the CN is included as one of the verified SANs.

Comment 10

[Ji Eun Seong]

Thank you for your quick review of our CPS.

We have been modifying the details of the CPS to reflect your recommendation comments and will update our CPS in 2 weeks.

Comment 11

[Ji Eun Seong]

Hello Ben,
We incorporated your feedback and then published our CPS version 1.5 on the official website.
Sections 1.1, 1.5.2, 3.1, 3.2.2.4, 4.1.1, 4.9.12, 6.7, and 7.1.4.2 were revised based on the feedback from Comment 9.
You can find the updated CPS from the CCADB URL since we also updated the CPS information.
CCADB URL: https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001323

Please let us know if there is any further information to proceed.

Comment 12

[Ji Eun Seong]

We have been waiting for your response regarding the updated CPS, revised according to your comments, for 4 months. Please review our feedback on your recommendation in Comment 9. We would appreciate it if you could let us know what remains to be done to proceed.

Comment 13

[Ji Eun Seong]

Attachment: MOIS GSSL CPS Updates and Response.pdf

We have been waiting for your response regarding the updated CPS, revised according to your comments, for 4 months. Please review our feedback on your recommendation in Comment 9. We would appreciate it if you could let us know what remains to be done to proceed.

Comment 14

[Ben Wilson]

Attachment: cps_v1.5_(ENG)-with-comments.docx

Comment 15

[Ben Wilson]

I have briefly reviewed version 1.5 of the GSSL Certification Practices Statement (https://ssl.gpki.go.kr/legal/cps/cps_v1.5_(ENG).pdf). I have attached a marked-up Word version here, which I had converted from the PDF. Here are my comments:

Section 1.1 – “This document is structured in accordance with the Internet Engineering Task Force (IETF) standard RFC 3647” and “In the event of any inconsistency between this document and the TLS Baseline Requirements, the TLS Baseline Requirements take precedence over this document.”

Comment: These are good.

Section 2 – “The GSSL CA records and keeps the document history according to section 5.4.” –

Comment: This might say “The GSSL CA records and keeps the document history of the CPS and links to all historic versions on its website.”

Section 3.1.5. – “The Fully Qualified Domain Name (FQDN) specified in the Subject Alternative Name is validated in accordance with section 3.2.2.4”

Comment: Good

Section 3.2.2.4

Comment: KLID / MOIS needs to allow and adopt automated methods of domain validation, such as ACME. Also, Methods 2 and 4 are being changed because of a requirement to conduct multi-perspective issuance corroboration (MPIC). KLID/MOIS needs to explain how it performs MPIC.

Section 3.4 – “Any third party with proof of key compromise may request certificate revocation.” – Good

Section 4.1.1 – “A subscriber certificate application must be submitted in an online application form on the website of the CA.”

Comment: The domain validation step in the request for an OV certificate needs to be automated to the maximum extent possible. For example, how does this process work with ACME?

Section 4.2.2 – “The Private key is weak (such as Debian weak key)”.

Comment: KLID must start screening for previously compromised keys. There are resources that can be used to perform this type of checking. https://cabforum.org/resources/tools/

Section 4.2.4

Comment: KLID/MOIS needs to ensure that the CAA domain in the CPS and in the CCADB are the same. (ssl.gpki.go.kr vs. gpki.go.kr).

Section 4.3

Comment: Has KLID/MOIS fully reviewed section 7.1 of the TLS BRs?

Section 4.3.1 – “The GSSL CA performs conformance linting prior to signing a Certificate over the pre-certificate and the issued certificate. Nonconformity found in linting is logged and issuance is rejected.”

Comment: More specificity is needed. For instance, has KLID/MOIS looked into using pkimetal? https://github.com/pkimetal/pkimetal

Section 4.3.2 – “As for subscriber certificate, notification is sent to the applicant via email.”

Comment: Has KLID considered an automated method of pushing a certificate to a server, e.g. ACME?

Section 4.9.2 – “Any third party with proof of key compromise may request certificate revocation.”

Comment: Good, but more details are needed in section 4.9.12. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation

Section 4.9.4 Revocation Request Grace Period

Comment: I don’t think this is the right language for this section.

Section 4.9.5 – “The GSSL CA investigates the facts and circumstances associated with the report and provides a preliminary report on its findings to the Subscriber or the entity that filed the problem report within 24 hours of after receiving the Certificate Problem Report. After the review of facts and circumstances, the GSSL CA cooperates with subscriber and entity, who reported the Certificate Problem Report or other revocation-related notices, to determine whether the Certificate shall be revoked or not. If revocation is required, the set time for the certificate revocation is within 24 hours.The period from receipt of the Certificate issue report or notice related to the revocation to the revocation of the Certificate shall not exceed the period specified in section 4.9.1.1, 4.9.1.2.”

Comment: Good

Section 4.9.12 – “Any third party with proof of key compromise may request certificate revocation”

Comment: Good - but what does the third party need to do to prove key compromise? What are the specific steps? More details are needed about the proof you require.

Section 5.7.3 – “In particular, once a Root CA private key is compromised, the GSSL CA informs browser vendors of the compromise and best estimate of the date of compromise.”

Comment: Browser providers / root stores should be informed of ANY CA private key compromise, not just those involving root CAs.

Section 9.6.3 – “Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if the CA discovers that the Certificate is being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.”

Comment: Due to numerous instances of delayed revocation by CAs over the past year (see https://bugzilla.mozilla.org/show_bug.cgi?id=1911183), this language needs to be strengthened much more to emphasize that the Subscriber MUST acknowledge and accept that MOIS/KLID SHALL revoke the certificate in accordance with and within the required timeframes of section 4.9.1.1 of the Baseline Requirements.

I invite others to review the CPS and make any other comments needed.

Thanks,

Ben

Comment 16

[Ji Eun Seong]

Thank you for your review of the MOIS CPS Version 1.5.

We have been incorporating your feedback and plan to update the CPS in January. Please note that we, MOIS, adhere to the CA Browser Forum Baseline Requirements regarding the MPIC and ACME in Section 3.2.2.4 of the CPS that you mentioned. I will follow up with you immediately after the updated CPS is published within two weeks.

Comment 17

[Ji Eun Seong]

Thank you for your feedback. We have published the updated CPS on our website. Please see CPS version 1.6 at https://ssl.gpki.go.kr/legal/cps/cps_v1.6_(ENG).pdf.

You can also find the document information from in the CCADB (link). Here are the sections we modified based on your comments in Comment 15.

Section 2 - The GSSL CA records and keeps the document history of the CPS and links to all historic versions on its website.
Section 3.2.2.4 - For all instances of verification of control or ownership of the domain, authentication of the Applicant’s (or the Applicant’s parent company’s, subsidiary company’s, or Affiliate’s, collectively referred to as “Applicants” for the purposes of this section) ownership or control of all requested FQDN(s) is done using one of the following methods of Section 3.2.2.4 of the Baseline Requirements for TLS:
• Email, Fax, SMS, or Postal Mail to Domain (3.2.2.4.2); or
• Constructed Email to Domain Contact (3.2.2.4.4); or
• DNS Change (3.2.2.4.7); or
• Agreed-Upon Change to Website - ACME (3.2.2.4.19)
Section 4.1.1 - All certificate applicants are required to register as members on the website and agree to the Subscriber Agreement.
• When applying for a certificate, they must submit a English business registration certificate necessary for organization validation.
• Domain validation is performed using one of the methods specified in Section 3.2.2.4.
• Certificate requests must contain domain names to be included in the SubjectAlternativeName extension (SAN) of Certificates.
Section 4.2.2 - The Private key is weak (such as Debian weak key, see https://wiki.debian.org/SSLkeys.
Section 4.2.4 - The following Issuer Domain Names in CAA ‘issue’ or ‘issuewild’ records recognize that the GSSL CA can issue a Subscriber Certificate.

• ssl.gpki.go.kr
  Section 4.3 - Certificates issued by the GSSL CA shall include the following information in accordance with the latest CA/Browser Forum Baseline Requirements:
  Section 4.3.1 - The GSSL CA performs conformance linting by linting tools prior to signing a Certificate over the pre-certificate and the issued certificate.
  Section 4.3.2 - The GSSL CA delivers within a reasonable time after issuing certificate. As for subscriber certificate, notification is sent to the applicant via email. Subscriber can download the certificate on WebSite or get by ACME client.
  Section 4.9.2 - Any subscriber with proof of key compromise MUST request certificate revocation.
  Section 4.9.4 - Subscribers are required to 24 hours suspend usage of Certificate Generation Key(Private Key) and Certificate and request revocation to GSSL Center in the following cases:
  Section 4.9.12 - Any subscriber with proof of key compromise MUST request certificate revocation.
  Section 5.7.3 - Once a Root CA or CA private key is compromised, the GSSL CA informs browser vendors of the compromise and best estimate of the date of compromise by our business continuity plan.
  Section 9.6.3 - The Applicant MUST follow the obligation and guarantees included in Subscriber Agreement or Terms of Use following:
  • Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;
  • Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key that correspond to the Public Key to be included in the requested Certificate(s);