1226100 - Add MOI GPKI Root CA certificate(s)

Status: RESOLVED WONTFIX

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

Description

[seyoon]

I am Sukeun Yoon of Korean Government Certification Management Authority which operates the Root CA of Korea government PKI.
On behalf of Ministry of the Interior (MOI) that is in charge of the Korean Government Certification Management Authority, we would like to add our Root certificate into Mozilla products. 


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

CA Name: Ministry of the Interior
Website: https://www.gpki.go.kr/eng/center/sub_01_01_01.jsp
One Paragraph Summary of CA, including the following:
As a government of the republic of Korea, Ministry of the Interior has a Root CA of Korea Government PKI.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Deloitte Anjin LLC
Auditor Website: http://www2.deloitte.com/kr/en/footerlinks/office-locator/deloitte-anjin-offices/seoul.html
Audit Document URL(s):
WebTrust for CAs: https://cert.webtrust.org/ViewSeal?id=1923 
WebTrust for CAs SSL Baseline : https://cert.webtrust.org/ViewSeal?id=1924 

Certificate Details
-------------------
(To be completed once for each certificate; note that we only include root
certificates in the store, not intermediates.)

Certificate Name: GPKIRootCA1


Certificate download URL (on CA website): https://www.gpki.go.kr/upload/download/GPKIRootCA1.zip
Version: V3
SHA1 Fingerprint:76 12 ed 9e 49 b3 65 b4 da d3 12 0c 01 e6 03 74 8d ae 8c f0
Public key length (for RSA, modulus length) in bits: 2048
Valid From (YYYY-MM-DD): 2011-08-03
Valid To (YYYY-MM-DD): 2031-08-31

CRL HTTP URL: https://www.gpki.go.kr/upload/crl/ARL/arl.zip

Class (domain-validated, identity/organizationally-validated or EV): DV, IV
CPS URL:https://www.gpki.go.kr/upload/download/1.1-GPKI_RootCA%20CPS.pdf

Comment 1

[Kathleen Wilson]

I am starting the Information Verification phase as described here:
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Kathleen Wilson]

I cannot browse to any of the information unless I already have this root cert installed, but there isn't a link where I can get the root cert without adding a security exception.

Please update this bug to provide all of the information listed here:
https://wiki.mozilla.org/CA:Information_checklist

Comment 4

[Channy Yun [:channy]]

seyoon, I think GPKI CA authority of MOI had to request this on behalf of gpki.go.kr. Please contact to GPKI CA authority and let them follow up this bug. 

FYI, Bug 335197 is holding issue to add KISA CA certificate in Mozilla Firefox.

Comment 5

[In-soo Kim]

(In reply to Kathleen Wilson from comment #2)
> I cannot browse to any of the information unless I already have this root
> cert installed, but there isn't a link where I can get the root cert without
> adding a security exception.
> 
> Please update this bug to provide all of the information listed here:
> https://wiki.mozilla.org/CA:Information_checklist

Kathleen, As Ms. Sukeun Yoon resigned, I would like to continue the inclusion of MOI GPKI root certificate.
Our Root CA certificate has already been included in Microsoft. If you use Internet Explorer and/or Chrome in Windows O/S, you can browse the information.
When Mozilla accepts our inclusion, all people can see the website through Firefox.

Comment 6

[In-soo Kim]

Attachment: GPKIRootCA1 certificate

For your information, I attached GPKI Root certificate which is vaild.

Comment 7

[David E. Ross]

(In reply to In-soo Kim from comment #5)
> Kathleen, As Ms. Sukeun Yoon resigned, I would like to continue the
> inclusion of MOI GPKI root certificate.
> Our Root CA certificate has already been included in Microsoft. If you use
> Internet Explorer and/or Chrome in Windows O/S, you can browse the
> information.
> When Mozilla accepts our inclusion, all people can see the website through
> Firefox.  

Whatever Microsoft does for approving root certificates does not allow for any shortcut in the Mozilla procedures.  Requested information (including public audit reports) must still be supplied to Mozilla.  Furthermore, a public review of this request will still be necessary.

Comment 8

[In-soo Kim]

Attachment: CRL-GPKIRootCA1

GPKIRootCA1 CRL

Comment 9

[In-soo Kim]

Attachment: CPS-GPKIRootCA1_CPS.pdf

GPKIRootCA CPS (Certificate Practice Statement) v1.0

Comment 10

[In-soo Kim]

(In reply to David E. Ross from comment #7)
> (In reply to In-soo Kim from comment #5)
> > Kathleen, As Ms. Sukeun Yoon resigned, I would like to continue the
> > inclusion of MOI GPKI root certificate.
> > Our Root CA certificate has already been included in Microsoft. If you use
> > Internet Explorer and/or Chrome in Windows O/S, you can browse the
> > information.
> > When Mozilla accepts our inclusion, all people can see the website through
> > Firefox.  
> 
> Whatever Microsoft does for approving root certificates does not allow for
> any shortcut in the Mozilla procedures.  Requested information (including
> public audit reports) must still be supplied to Mozilla.  Furthermore, a
> public review of this request will still be necessary.

David, 
I fully understand that there are different policies and procedures between Microsoft and Mozilla. We are ready to support all information required to Mozilla. Attached please find the certificate, CRL, and CPS document of GPKI. 

You can find the public audit reports as you mentioned by clicking the below links.
Audit Document URL(s):
WebTrust for CAs: https://cert.webtrust.org/ViewSeal?id=1923 
WebTrust for CAs SSL Baseline : https://cert.webtrust.org/ViewSeal?id=1924 

And let me know if you need more information that you think as required for going forward.

Comment 11

[Kathleen Wilson]

Attachment: 1226100-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please comment in this bug to provide corrections and the requested information (search for NEED in the attached document)

Comment 12

[In-soo Kim]

Attachment: CA-Information_modifiy_v40_20160626_for Bugzilla.pdf

I fulfilled MOI Root CA information which is required for verification on 1226100-CAInformation.pdf 
Let me know if the verification is done by the added information.

Comment 13

[In-soo Kim]

I would like you to check the attached document with added information for verification which was uploaded a month ago. 
Let us know if the verification is complete.

Comment 14

[In-soo Kim]

I have been waiting for your feedback for months in the face of lots of questions and complains regarding the inclusion of our certificates to Firefox. 
Let me know if the verification on your side is complete.

Comment 15

[Aaron Wu]

Attachment: RootCase-GPKI_20160918.pdf

Comment 16

[Aaron Wu]

Attachment: Case-GPKI_20160918.pdf

Comment 17

[Aaron Wu]

Hi In-soo Kim,

Thank you for your waiting, we are working on the case you requested.

We've input your info. into Salesforce and doing information verification.  Please review two attached documents and look for the word "NEED" to see what information still needs to be provided. 

One thing to mention that we need the CP/CPS document translated in English, Not only just in the phase of information verification, but in the discussion phase people will ask CAs to provide translation into English of the entire CP/CPS. Once the English translated Document provided, it will speed up our verification and quickly move to next phase.

Thank you!

Comment 18

[In-soo Kim]

(In reply to Aaron Wu from comment #15)
> Created attachment 8792326 [details]
> RootCase-GPKI_20160918.pdf

I attached CA responses on Need Clarification From CA and Need Response From CA items of RootCase-GPKI_20160918.pdf attached on September 18.

Comment 19

[In-soo Kim]

Attachment: CA Responsed RootCase-GPKI_20160918.pdf.pdf

I attached CA responses on Need Clarification From CA and Need Response From CA items of RootCase-GPKI_20160918.pdf attached on September 18.

Comment 20

[In-soo Kim]

Attachment: GPKI Certification Practice Statement(CPS)_v1.0.pdf

(In reply to Aaron Wu from comment #17)
> Hi In-soo Kim,
> 
> Thank you for your waiting, we are working on the case you requested.
> 
> We've input your info. into Salesforce and doing information verification. 
> Please review two attached documents and look for the word "NEED" to see
> what information still needs to be provided. 
> 
> One thing to mention that we need the CP/CPS document translated in English,
> Not only just in the phase of information verification, but in the
> discussion phase people will ask CAs to provide translation into English of
> the entire CP/CPS. Once the English translated Document provided, it will
> speed up our verification and quickly move to next phase.
> 
> Thank you!

Hi Aaron Wu, I attached English translation document of Root CA CPS.

Comment 21

[In-soo Kim]

Attachment: GPKI Certification Practice Statement(CPS)_v1.0.pdf

(In reply to Aaron Wu from comment #17)
> Hi In-soo Kim,
> 
> Thank you for your waiting, we are working on the case you requested.
> 
> We've input your info. into Salesforce and doing information verification. 
> Please review two attached documents and look for the word "NEED" to see
> what information still needs to be provided. 
> 
> One thing to mention that we need the CP/CPS document translated in English,
> Not only just in the phase of information verification, but in the
> discussion phase people will ask CAs to provide translation into English of
> the entire CP/CPS. Once the English translated Document provided, it will
> speed up our verification and quickly move to next phase.
> 
> Thank you!


Hi Aaron Wu, I attached English translation document of Root CA CPS.

Comment 22

[Aaron Wu]

Thanks Kim!

We are proceeding in information verification based on the document you provided and will feedback you soon.

Thanks,
Aaron

Comment 23

[In-soo Kim]

Thanks for your reply. 

We are looking for feedback on our Root CA certificate. It would be appreciated if you let us know when the inforation verification is complete.

Comment 24

[Aaron Wu]

Attachment: GPKI_CA.pdf

Comment 25

[Aaron Wu]

Hi Kim,

The Root CA is verifying and almost done, now we need your input as attachment on Comment#24 which including Recommended Practices with 12 items and Problematic Practices with 14 items. These information are very helpful when it moves to next stage as Public Discussion.

Thank you!

Comment 26

[In-soo Kim]

Attachment: CA Resonpse_GPKI CA_20161128.pdf

Comment 27

[In-soo Kim]

Comment on attachment 8814760 [details]
CA Resonpse_GPKI CA_20161128.pdf

Hi Aaron Wu, 

I attached CA Resonpse_GPKI CA_20161128.pdf

Thank you

Comment 28

[Aaron Wu]

Thanks Kim!

We are working on the information verification based on your response as attached, will inform you once done and ready to move to next stage.

Thanks,
Aaron

Comment 29

[In-soo Kim]

Hi Aaron Wu, 

We are still waiting for your response and we also need to speed up for the next. 
We appreciate your efforts but we should get an official comment from Firefox within the end of this month. 

Thank you

Comment 30

[Aaron Wu]

Hi Kim,

Thanks for your waiting, please note below
"Note: *A Mozilla representative processes CA Bug updates for root inclusion/change requests on a first-in, first-out basis. The Mozilla representative will add a comment to the bug when the update has been processed, and Bugzilla will send an email notification to the bug submitter and owner, and everyone on the bug CC list."

https://wiki.mozilla.org/CA:How_to_apply#Timeline


We got many cases ahead and will complete IV of this case soon, thank you and please stay tuned.

Comment 31

[Aaron Wu]

Hi Kim,

Thanks for your waiting! We completed the 2nd Information Verification. For root CA case, we've verified and updated in Salesforce, thanks for your info. update.

For CA's Response to Recommended Practices, some items please provide sufficient information based on the following wiki to fill in and it will help speed up a CA's application for inclusion and maximize the chances of its application being approved.

wiki : https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices

Take "CA Hierarchy" as example
- The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs
- The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.

Please refer to the wiki above and update Recommended Practices

2) CA Hierarchy
3) Audit Criteria
4) Document Handling of IDNs in CP/CPS
6) Verifying Domain Name Ownership
12) Network Security Controls

Once updated and verified, we can move to next stage.

Thank you!

Comment 32

[Ryan Sleevi]

In the effort of providing an earlier feedback cycle for the CA, I do want to draw Kathleen and Aaron's attention to the responses in https://bugzilla.mozilla.org/show_bug.cgi?id=1226100#c27 regarding sub-CAs

The "Publicly Available CP and CPS" answer notes, for three sub-CAs:
(3) Supreme Court of Korea,
Confidential document.
(4) Supreme Prosecutors' Office
Confidential document.
(5) Military Manpower Administration
Confidential document.

Similarly, for the "Publicly Disclosed and Audited sub-CAs"
(3) Supreme Court of Korea CA :
Confidential.
(4) Supreme Prosecutors' Office CA :
Confidential.
(5) Military Manpower Administration CA :
Confidential.


I believe this runs afoul of the program requirements listed in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ , namely

"All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited."

As this could significantly affect the request, it seems worthwhile to highlight this now, early in the inclusion process.

Comment 33

[Hyunwook Kim]

Attachment: CA response for comment 31

Dear Aaron Wu and all attendees, 

As of today, I'm a new person who in charge of MOI GPKI instead of Mr. In-soo Kim.

I would like to continue the inclusion of MOI GPKI root certificate.

Let me attach the response for Comment #31.

Please review our response again. 

I appreciate your consideration in advance.

Comment 34

[Kathleen Wilson]

(In reply to Hyunwook Kim from comment #33)
> As of today, I'm a new person who in charge of MOI GPKI instead of Mr.
> In-soo Kim.


Please see Comment #32. That is a show-stopper. We cannot move forward with evaluating this request if there are non-technically-constrained intermediate certificates for which the CP/CPS/Audit documents are confidential.

Comment 35

[Hyunwook Kim]

 
> Please see Comment #32. That is a show-stopper. We cannot move forward with
> evaluating this request if there are non-technically-constrained
> intermediate certificates for which the CP/CPS/Audit documents are
> confidential.

Supreme Court of Korea CA, Supreme Prosecutors' Office CA, and Military Manpower Administration CA don't issue certificates for SSLs, email protection, and code-signing. It would be appreciated if you give us your opinion regarding that these CAs need to be complied with the Mozilla policy and CA Browser Forum requirements.

Comment 36

[Ryan Sleevi]

Mozilla Policy tries to avoid whether they intend to issue, and instead require demonstration that they're not technically capable of issuance, or accompanied with a Public Audit, which serves to effectively demonstrate that it does not issue.

This is why it is very important to technically constrain such sub-CAs, by ensuring that they have EKUs but not id-kp-serverAuth.

Does the Policy in Comment 32 help clarify? That's the policy and expectation, but please ask if you have any questions about any of it, that way we can make sure you get Mozilla everything it needs.

Comment 37

[Hyunwook Kim]

(In reply to Ryan Sleevi from comment #36)
> Mozilla Policy tries to avoid whether they intend to issue, and instead
> require demonstration that they're not technically capable of issuance, or
> accompanied with a Public Audit, which serves to effectively demonstrate
> that it does not issue.

Ryan, 
I think that we have different situation in Korea. Any government Certificate Authority shall be accredited by the Ministry of the Interior according to the Enforcement decree of Electronic Government Act of Korea. Thus, the subordinate CA policy is managed and controlled by the Act and subordinate regulations. 

Article 34 (Administrative Digital Signature Management) (3) Details of the rules of administrative digital signature certification duties and other management of certificates shall be prescribed and announced by the Minister of the Interior. <Enforcement decree of Electronic Government Act>

Comment 38

[Ryan Sleevi]

(In reply to Hyunwook Kim from comment #37)
> (In reply to Ryan Sleevi from comment #36)
> > Mozilla Policy tries to avoid whether they intend to issue, and instead
> > require demonstration that they're not technically capable of issuance, or
> > accompanied with a Public Audit, which serves to effectively demonstrate
> > that it does not issue.
> 
> Ryan, 
> I think that we have different situation in Korea. Any government
> Certificate Authority shall be accredited by the Ministry of the Interior
> according to the Enforcement decree of Electronic Government Act of Korea.
> Thus, the subordinate CA policy is managed and controlled by the Act and
> subordinate regulations. 

I don't think the Government of Korea is unique in this regard. However, in order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent policy that describes the expectations for all CAs that will be trusted within its program. Occasionally, this does run into conflict with various nationally-established PKIs. You can see many such requests in various states in Bugzilla, but there is one consistent application of policy.

This is very important for Mozilla Firefox, a globally distributed product, to provide a consistent level of assurance to its users. Unlike Microsoft, which is the only program I'm aware of that allows for exceptions for Government CAs (provided they are name constrained), Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of issuance.

If you have intermediates for which you cannot disclose, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with Mozilla CA Certificate Policy, is to use Technically Constrained Subordinate CAs - as defined within the Baseline Requirements and as reflected within the Mozilla policy. Such TCSCAs are technically limited from the issuance of TLS certificates, and by doing so, are allowed to be operated in a way that is not consistent with the Baseline Requirements nor compliant with Mozilla Policy.

For example, if these subCAs are not used for the production of TLS certificates, but only identity certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it *lacks* the id-kp-serverAuth and anyExtendedKeyUsage extensions.

Alternatively, you can consider restructuring a CA hierarchy such that you have

   /-Private Sub CA 1
  /--Private Sub CA 2
Root
  \
   \-BR-compliant Public Intermediate
        \
         \----BR-compliant SubCA1
          \---BR-compliant SubCA2
           \--BR-compliant SubCA3

That is, in this structure, an additional intermediate is inserted into your PKI which distinguishes the "private" (confidential) sub-CAs, and the publicly audited, publicly disclosed set of sub-CAs. In this scenario, rather than all chaining directly to the Root, they transit a newly introduced intermediate. It is this newly introduced intermediate that you would 'apply' for inclusion to Mozilla as the root, even if operationally, your government might use and rely on "Root" for the broader purpose of digital signature identification or operational management.

The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.

Does that help clarify why this would prevent progressing? If you're unable to publicly disclose and audit those sub-CAs, a core requirement of Mozilla's CA Certificate Policy, then you will need to rearchitect your PKI before the inclusion request will be able to conclude, under the current policy.

Comment 39

[Hyunwook Kim]

(In reply to Ryan Sleevi from comment #38)
> (In reply to Hyunwook Kim from comment #37)
> > (In reply to Ryan Sleevi from comment #36)

 Hi, Aaron

 According to RFC 5280, EKU extension fields of the Sub-CAs have set optional. We considered the alternative way you had suggested, but it’s so hard to reconstruct a CA hierarchy by inserting an additional intermediate CA. The Act of e-government states that any licensed CA shall be directly under a Root CA without any intermediate CA between them.

 However, we are very interested in trust anchor you mentioned. If Mozilla policy allows part of sub-CAs as trust anchors, Can each CA which issues SSL certificates request its CA certificate inclusion into Mozilla products separately? If so, Ministry of the Interior and Ministry of Education CAs fulfill the CA Browser Forum BR.

Comment 40

[Kathleen Wilson]

(In reply to Hyunwook Kim from comment #39)
>  However, we are very interested in trust anchor you mentioned. If Mozilla
> policy allows part of sub-CAs as trust anchors, Can each CA which issues SSL
> certificates request its CA certificate inclusion into Mozilla products
> separately? If so, Ministry of the Interior and Ministry of Education CAs
> fulfill the CA Browser Forum BR.

Mozilla allows subCAs to be included as separate trust anchors. 

An example of this is in our treatment of super-CAs, as described here: 
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

How many subCAs would you request to be included?
What are their validity periods?

Notes:
1) Our process is intentionally slow, as described here: https://wiki.mozilla.org/CA
2) CP/CPS/audit information for the trust anchors and their subCAs must be publicly disclosed (not confidential).

Comment 41

[Hyunwook Kim]

(In reply to Kathleen Wilson from comment #40)
> (In reply to Hyunwook Kim from comment #39)
> How many subCAs would you request to be included?
> What are their validity periods?

We want two subCAs to be included in the browser as mentioned below.

Ministry of Government Administration and Home Affairs CA is effective from 22/Sep/2011 to 22/Sep/2021.
Ministry of Education CA is effective from 15/Dec/2011 to 15/Dec/2021.
The names of government ministry are based on CPS and likely to be changed by governmental reorganization.

Comment 42

[Kathleen Wilson]

(In reply to Hyunwook Kim from comment #41)
> We want two subCAs to be included in the browser as mentioned below.
> 
> Ministry of Government Administration and Home Affairs CA is effective from
> 22/Sep/2011 to 22/Sep/2021.
> Ministry of Education CA is effective from 15/Dec/2011 to 15/Dec/2021.
> The names of government ministry are based on CPS and likely to be changed
> by governmental reorganization.

For both 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)

Comment 43

[Hyunwook Kim]

> For both 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)

Kathleen, 

Regarding 'CA:Information_checklist', you can examine 2 attachments titled '1226100-CAInformation.pdf' and 'CA response for comment 31'. Referentially, you can see the Government PKI of Korea hierarchical structure in 'CA response for comment 31'. And the Ministry of the Interior and Ministry of Education CAs have its own CPS and conducted internal audits by themselves. According to Sub CAs Operated by 3rd parties of CA:Information_Checklist, we will apply for inclusion for each CA as separate trust anchors, in terms of Super CA which Ryan mentioned above, if Mozilla accepts.

Comment 44

[Hyunwook Kim]

Attachment: MOI Sub-CA_Information Checklist.pdf

Regarding 'CA:Information_checklist', let me attach the response 'MOI Sub-CA_Information Checklist'.
Please review it and feedback me what I prepare for going to next verification. 

Thanks,
Kim

Comment 45

[Hyunwook Kim]

Attachment: MOI Sub-CA_Information Checklist.pdf

Regarding 'CA:Information_checklist', let me attach the response 'MOI Sub-CA_Information Checklist'.
Please review it and feedback me what I prepare for going to next verification. 

Thanks,
Kim

Comment 46

[Hyunwook Kim]

(In reply to Kathleen Wilson from comment #42)
> (In reply to Hyunwook Kim from comment #41)
> > We want two subCAs to be included in the browser as mentioned below.
> > 
> > Ministry of Government Administration and Home Affairs CA is effective from
> > 22/Sep/2011 to 22/Sep/2021.
> > Ministry of Education CA is effective from 15/Dec/2011 to 15/Dec/2021.
> > The names of government ministry are based on CPS and likely to be changed
> > by governmental reorganization.
> 
> For both 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)

Kathleen,

As you requested I attached our Sub-CA certificates information as a "root certificate" for the purpose of Mozilla process on Comment 45 Attachment file updated on April 26. You can find the details of the Sub-CA certificates in there. Please let me know if you need more information. 

Thanks, 
Kim

Comment 47

[Hyunwook Kim]

Kathleen,

We consider that it is reasonable to classify our Sub-CAs issuing SSL certificates and others under the Root certificate. If possible, we will prepare the Sub-CA separate inclusion as Ryan Sleevi suggested on Comment 38. 

Please give me the ways to proceed next step.

Thanks,
Kim

Comment 48

[Firefox Bug Husbandry Bot]

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

Comment 49

[Kathleen Wilson]

Per Comment #38, I am going to close this bug, because there are private subCAs in this root's hierarchy that the CA does not want to disclose. So, even though the subCAs are operated by the same organization, we will treat the applicable subCA certs as separate trust anchors and consider them for inclusion directly, such as in Bug #1377389.

Comment 50

[KimMinsu]

Supreme Court of Korea CA : https://crt.sh/?icaid=1457&identity=%

Comment 51

[KimMinsu]

https://crt.sh/?icaid=1457&identity=%25