NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson]

Dear All,

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process,
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9). Mozilla is considering approval of NAVER Business Platform
Corp.’s request to include the NAVER Global Root Certification Authority as
a trust anchor with the websites trust bit enabled, as documented in the
following Bugzilla case:
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
3-week comment period, after which if no concerns are raised, we will close
the discussion and the request may proceed to the approval phase (Step 10).

*A Summary of Information Gathered and Verified appears here in the CCADB:*

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000261

*NAVER Global Root Certification Authority, *valid from 8/18/2017 to
8/18/2037

SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265

https://crt.sh/?id=1321953839

*Root Certificate Download:*

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt


*CP/CPS:*

Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
through 42 in Bugzilla contain discussion concerning the CPS and revisions
thereto.

Current CPS is version 1.4.3:

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf

Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do

*BR Self Assessment* (Excel file) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9063955

*Audits:* Annual audits are performed by Deloitte according to the
WebTrust Standard and WebTrust Baseline Requirements audit criteria. See
webtrust.org. The last complete audit period for NAVER was from 1 December
2018 to 30 November 2019 and no issues were found. However, the audit
report was dated 28 April 2020, which was more than three months following
the end of the audit period. The explanation for the delay in obtaining the
audit report was as follows, “NBP had received a notification mail on
updating the audit information from CCADB support in March since the Root
certificate is only included into Microsoft Root Program. According to
instructions on the email, I explained that NBP would submit the audit
update information in April to Microsoft.” The current audit period ends
30 November 2020.

*Mis-Issuances *

According to crt.sh and censys.io, the issuing CA under this root
(NAVER Secure Certification Authority 1) has issued approximately 80
certificates. I ran the following query for the issuing CA to identify any
mis-issuances:
https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-08-18,
and during the course of our review, we identified six test certificates
with errors. (Such certificates have either been revoked or have expired).
See:

https://crt.sh/?id=2132664529&opt=cablint,zlint,x509lint

https://crt.sh/?id=2102184572&opt=cablint,zlint,x509lint

https://crt.sh/?id=1478365347&opt=cablint,zlint,x509lint

https://crt.sh/?id=2149282089&opt=cablint,zlint,x509lint

https://crt.sh/?id=2149282369&opt=cablint,zlint,x509lint

https://crt.sh/?id=2282123486&opt=cablint,zlint,x509lint

The explanation provided (
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was “Regarding
CA/B Forum and X.509 lint tests NBP figured out two(2) certificates which
were not complied with BRs right after issuing them. The domains on SANs of
the certificates were owned and controlled by NBP. They were immediately
revoked according to CA procedures. For ZLint tests, the certificate (CN=
test2-certificate.naver.com) had been issued and became expired in
compliance with CA Browser Forum BRs and RFC 5280. I understand there is a
specific Mozilla policy on Authority Key IDs. NBP already fixed the system
functions. There is no such valid certificate and NBP CA currently issues
certificates fully complied with the Mozilla policy. You can see the new
certificate (CN= test2-certificate.naver.com) was issued without any error
at https://crt.sh/?id=2824319278.”

I have no further questions or concerns at this time, however I urge anyone
with concerns or questions to raise them by replying to this list under the
subject heading above.

Again, this email begins a three-week public discussion period, which I’m
scheduling to close on Monday, 2-November-2020.

Sincerely yours,

Ben Wilson

Mozilla Root Program

[George]

Minor but it seems like all certificates with a stateOrProvinceName field are misissued. The ST field should probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city.



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> Dear All,
>
> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process,
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
> through 9). Mozilla is considering approval of NAVER Business Platform
> Corp.’s request to include the NAVER Global Root Certification Authority as
> a trust anchor with the websites trust bit enabled, as documented in the
> following Bugzilla case:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
> 3-week comment period, after which if no concerns are raised, we will close
> the discussion and the request may proceed to the approval phase (Step 10).
>

> A Summary of Information Gathered and Verified appears here in the CCADB:
>

> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000261
>
> *NAVER Global Root Certification Authority, *valid from 8/18/2017 to
> 8/18/2037
>
> SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
>
> https://crt.sh/?id=1321953839
>

> Root Certificate Download:
>
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt
>
> CP/CPS:

>
> Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> through 42 in Bugzilla contain discussion concerning the CPS and revisions
> thereto.
>
> Current CPS is version 1.4.3:
>

> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP Certification Practice Statement v1.4.3.pdf
>
> Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do
>
> BR Self Assessment (Excel file) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9063955
>
> Audits: Annual audits are performed by Deloitte according to the

> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Ben Wilson]

Here is NAVER's response which I am forwarding from them:

Here is NAVER Business Platform's response to the comment:
-----------------------------
Hello, I am Sooyoung at NAVER Business Platform.
As George mentioned, all the certificates, with both of city and province
names in stateOrProvinceName field, were issued to NAVER Business Platform
(NBP) for test domains. The addresses were verified correctly when issuing
them. NBP reflected George’s comment and has fixed the DN structure. You
can directly check the issued certificate including the new DN (L is
"Seongnam-si" as city name and S field is "Gyeonggi-do" as province name)
as below.
https://crt.sh/?id=3510606493
NBP also added additional verification process, in compliance with ISO
3166-2, in order to put province information correctly in S field of user
DN for newly issued certificates.
-----------------------------
Best Regards,
Sooyoung Eo

[Matthias van de Meent]

Hi,

In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following:

> 4.9.3 Procedure for Revocation Request
> The NAVER BUSINESS PLATFORM processes a revocation request as follows:
> [...]
> 4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel begin investigating the request within 24 hours after receipt and decide whether revocation is appropriate based on the following criteria:
> a. [...], b. [...], c. [...], d. [...]
> e. Relevant legislation.

The wording here is concerning, as it points to potential legislation
that could disallow NAVER from revoking problematic certificates. Also
of note is that this 'relevant legislation' is not referenced in
section 9.14, Governing Law, nor in 9.16.3, Severability (as required
per BRs 9.16.3).

I also noticed that the "All verification activities" type of event is
not recorded, or at least not documented as such. This is a
requirement from BRs 5.4.1(2)(2).


Regards,

Matthias

On Sat, 10 Oct 2020 at 00:09, Ben Wilson via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
>
> Dear All,
>
> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process,
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
> through 9). Mozilla is considering approval of NAVER Business Platform
> Corp.’s request to include the NAVER Global Root Certification Authority as
> a trust anchor with the websites trust bit enabled, as documented in the
> following Bugzilla case:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
> 3-week comment period, after which if no concerns are raised, we will close
> the discussion and the request may proceed to the approval phase (Step 10).
>

> *A Summary of Information Gathered and Verified appears here in the CCADB:*

>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000261
>
> *NAVER Global Root Certification Authority, *valid from 8/18/2017 to
> 8/18/2037
>
> SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
>
> https://crt.sh/?id=1321953839
>

> *Root Certificate Download:*
>
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt
>
>
> *CP/CPS:*
>

> Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> through 42 in Bugzilla contain discussion concerning the CPS and revisions
> thereto.
>
> Current CPS is version 1.4.3:
>

> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf
>
> Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do
>

> *BR Self Assessment* (Excel file) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9063955
>
> *Audits:* Annual audits are performed by Deloitte according to the

> _______________________________________________

[Ryan Sleevi]

On Wed, Oct 21, 2020 at 2:09 PM Matthias van de Meent via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> Hi,
>
> In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following:
>
> > 4.9.3 Procedure for Revocation Request
> > The NAVER BUSINESS PLATFORM processes a revocation request as follows:
> > [...]
> > 4. For requests from third parties, The NAVER BUSINESS PLATFORM
> personnel begin investigating the request within 24 hours after receipt and
> decide whether revocation is appropriate based on the following criteria:
> > a. [...], b. [...], c. [...], d. [...]
> > e. Relevant legislation.
>
> The wording here is concerning, as it points to potential legislation
> that could disallow NAVER from revoking problematic certificates. Also
> of note is that this 'relevant legislation' is not referenced in
> section 9.14, Governing Law, nor in 9.16.3, Severability (as required
> per BRs 9.16.3).
>

If I understand your concern, you're concerned about a decision to /not/
revoke a given certificate, correct? You're indeed accurate that a
certificate that violated the BRs, but was not revoked according to
relevant legislation, would be a BR violation and the CA would have been
required to previously disclose this according to 9.16.3.

However, CAs are also free to *add* reasons for revocation, and to consider
part of their investigation. relevant legislation which might lead to
revocation even if it wasn't a violation of NAVER's CP/CPS. This is totally
fine, and all CAs are entitled to add additional requirements, and for
relying parties/root programs to consider those reasons relevant to their
user communities.

Note that, in this case, the particular language you're concerned about is
part of the BRs themselves, in 4.9.5. However, this is about "when" to
revoke.

I think you raise an interesting point that would benefit from
clarification from NAVER, because I think you're correct that we should be
concerned that the shift from "when" to revoke has become "whether" to
revoke, and that is an important difference.

> I also noticed that the "All verification activities" type of event is
> not recorded, or at least not documented as such. This is a
> requirement from BRs 5.4.1(2)(2).
>

Thanks for the excellent attention to detail! I agree, this would be
concerning, especially given the importance this log has been in
investigating CA misissuance in the past.

[Sooyoung Eo]

Hi,
Please see NBP’s response to Matthias and Ryan’s comments.

2020년 10월 22일 목요일 오전 3시 29분 40초 UTC+9에 Ryan Sleevi님이 작성한 내용:

For Ryan’s comment on section 9.14 and 9.16.3 of NBP’s CPS, NBP would have stipulated an issue in section 9.14 and I would have notified it to CA Browser Forum in advance if there had been national laws and regulations which affect certificates revocation in our territory. However, we found that there are no South Korea’s laws and regulations which affect or refuse the revocation of certificates that violated the BRs issued by a commercial CA. A certificate that violated the BRs, but was not revoked according to relevant legislation, has not happened since NBP started providing certificate services.

> Note that, in this case, the particular language you're concerned about is
> part of the BRs themselves, in 4.9.5. However, this is about "when" to
> revoke.
>
> I think you raise an interesting point that would benefit from
> clarification from NAVER, because I think you're correct that we should be
> concerned that the shift from "when" to revoke has become "whether" to
> revoke, and that is an important difference.

I agree on the above Ryan’s comment. NBP will exclude the criteria that CA should consider to select the revocation time in section 4.9.3 and add them in Section 4.9.5. As NBP complies with the laws of the Republic of Korea, the following will be added in section 9.14 of NBP CPS.
“This CPS is governed, construed and interpreted in accordance with the laws of Republic of Korea. This choice of law is made to ensure uniform interpretation of this CPS, regardless of the place of residence or place of use of NAVER BUSINESS PLATFORM Certificates or other products and services. The law of Republic of Korea applies also to all NAVER BUSINESS PLATFORM commercial or contractual relationships in which this CPS may apply or quoted implicitly or explicitly in relation to NAVER BUSINESS PLATFORM products and services where NAVER BUSINESS PLATFORM acts as a provider, supplier, beneficiary receiver or otherwise."

> > I also noticed that the "All verification activities" type of event is
> > not recorded, or at least not documented as such. This is a
> > requirement from BRs 5.4.1(2)(2).
> >
> Thanks for the excellent attention to detail! I agree, this would be
> concerning, especially given the importance this log has been in
> investigating CA misissuance in the past.

Actually, NBP records all verification activities as well as other events stipulated in BRs section 5.4.1. I think that all verification activities is included in NBP CPS, section 5.4.1 Certificate lifecycle-related event. However, as Matthias mentioned, it may not look clearly. I would consider modifying the CPS section according to BRs section if it's necessary to avoid ambiguity.

[Sooyoung Eo]

2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:

[Ben Wilson]

The 3-week public discussion was to close on Monday, but I'd like Naver to
provide any further final comments and give anyone else an opportunity to
comment through this Thursday, and then I will proceed with Steps 6-10
(summarize matters, note any remaining items, and make a last call for
objections).

On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:

> Hello, I am Sooyoung at NAVER Business Platform.
> ​
> As George mentioned, all the certificates, with both of city and province
> names in stateOrProvinceName field, were issued to NAVER Business Platform
> (NBP) for test domains. The addresses were verified correctly when issuing
> them. NBP reflected George’s comment and has fixed the DN structure. You
> can directly check the issued certificate including the new DN (L is
> "Seongnam-si" as city name and S field is "Gyeonggi-do" as province name)
> as below.
> https://crt.sh/?id=3510606493
> ​
> NBP also added additional verification process, in compliance with ISO
> 3166-2, in order to put province information correctly in S field of user
> DN for newly issued certificates.

> _______________________________________________

[Sooyoung Eo]

Thank you all for the comments during the public discussion phase.
All matters raised in this public discussion has been fixed and then published
our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14, and 9.16.3.

You can find the revised CPS v1.5.0 at our repository.
https://certificate.naver.com/bbs/initCrtfcJob.do
(directly download link: https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf)

To minimize confusion, I would like to metion that "NAVER BUSINESS PLATFORM"
has been renamed to "NAVER Cloud" without any changes on the ownership of
the company and Certification Authority on October 26, 2020.

Kind Regards,
Sooyoung Eo


2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:

[Ben Wilson]

Step 6 of CA Application Process
<https://wiki.mozilla.org/CA/Application_Process>: *Summary of Discussion
and Resulting Decision:*

One commenter stated that it appeared that a few certificates were
misissued, i.e. that the stateOrProvinceName field (“S” field) should
probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city. A
NAVER representative responded that it had fixed the DN structure with L
equal to "Seongnam-si" as city name and S field as "Gyeonggi-do" for
province name. NAVER also added a procedure, in compliance with ISO
3166-2, to put province information correctly in the S field of user DN for
newly issued certificates.

A second commenter noted that: (1) wording in the CPS could allow NAVER to
avoid revoking problematic certificates by relying on Korean law; (2)
“relevant legislation” was not referenced in
sections 9.14 and 9.16.3 as required by BR section 9.16.3; and (3) the list
of events logged did not include "All verification activities" as required
by BR section 5.4.1(2).

Responses to the foregoing included the following: (1) a certificate not
revoked because of Korean law would be a BR violation and the CA would be
required to previously disclose this according to BR section 9.16.3 (the
conflicting requirement could be modified “to the minimum extent necessary
to make the requirement valid and legal” and the CA would have to notify
the CA/Browser Forum of such practice change so that the Forum could react
appropriately. NAVER also stated, “we found that there are no South Korea’s

laws and regulations which affect or refuse the revocation of certificates

that violated the BRs issued by a commercial CA”. (2) A third commenter
stated, “Note that, in this case, the particular language you're concerned

about is part of the BRs themselves, in 4.9.5. However, this is about
‘when’ to revoke. I think you raise an interesting point that would
benefit from clarification from NAVER, because I think you're correct that
we should be concerned that the shift from ‘when’ to revoke has become

‘whether’ to revoke, and that is an important difference.” As a result of
these comments, NAVER amended sections 4.9.5, 9.14, and 9.16.3.

Section 4.9.5 of the NAVER CPS now reads, “The period from receipt of the
Certificate Problem Report or revocation-related notice to published
revocation must not exceed the time frame set forth in Section 4.9.1.1. The
date selected by NAVER Cloud will consider the following criteria: …
Relevant legislation.”

Section 9.14 of the NAVER CPS now states, “This CPS is governed, construed

and interpreted in accordance with the laws of Republic of Korea. This
choice of law is made to ensure uniform interpretation of this CPS,

regardless of the place of residence or place of use of NAVER Cloud

Certificates or other products and services. The law of Republic of Korea

applies also to all NAVER Cloud commercial or contractual relationships in

which this CPS may apply or quoted implicitly or explicitly in relation to

NAVER Cloud products and services where NAVER Cloud acts as a provider,
supplier, beneficiary receiver or otherwise.”

(Note that section 1.1 of the NAVER CPS states, “In the event of any
inconsistency between this CPS and the Baseline Requirements, the Baseline
Requirements take precedence over this document.”)

Section 9.16.3 has been amended by adding a paragraph reading, “In the
event of a conflict between CABF Baseline Requirements and a law,
regulation or government order (hereinafter ‘Law’) of any jurisdiction in
which a CA operates or issues certificates, NAVER Cloud modifies any
conflicting requirement to the minimum extent necessary to make the
requirement valid and legal in the jurisdiction. This applies only to
operations or certificate issuances that are subject to that Law. In such
event, NAVER Cloud immediately (and prior to issuing a certificate under
the modified requirement) includes in Section 9.16.3 of this CPS a detailed
reference to the Law requiring a modification of these Requirements under
this section, and the specific modification to these Requirements
implemented by NAVER Cloud.”

(3) Section 5.4.1 now states that “NAVER Cloud records at least the
following events: … 2. Subscriber Certificate lifecycle management events,
including: … b. All verification activities stipulated in these
Requirements and the CA’s Certification Practice Statement”.

A key take-away from a review of these comments and responses is the need
for each CA’s CPS language to provide a firm commitment to revoke
certificates on a timely basis. I think members of the Mozilla community do
not want to have to worry about “when” or “whether” a certificate will be
revoked. In sections 4.9.1.1 and 4.9.5 of the NAVER CPS, NAVER has adopted
essentially the 24-hour and 5-day timeframes of sections 4.9.1.1 and 4.9.5
of the Baseline Requirements. Certainly, all CAs could improve the
descriptions of their revocation processes, but this language in the NAVER
CPS meets the minimum requirements. Hopefully, NAVER and other CAs will not
only strive to improve their CPS revocation language, but also strive to
revoke certificates quickly when one of the criteria is met.

Are there any final comments or issues that have not been addressed? If
not, I will be closing public discussion tomorrow [Step 9] and giving
notice that it is Mozilla’s intent to approve NAVER's request for inclusion
[Step 10].

Thanks,

Ben

On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thank you all for the comments during the public discussion phase.
> All matters raised in this public discussion has been fixed and then
> published
> our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14,
> and 9.16.3.
>
> You can find the revised CPS v1.5.0 at our repository.
> https://certificate.naver.com/bbs/initCrtfcJob.do
> (directly download link:
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf
> )
>
> To minimize confusion, I would like to metion that "NAVER BUSINESS
> PLATFORM"
> has been renamed to "NAVER Cloud" without any changes on the ownership of
> the company and Certification Authority on October 26, 2020.
>
> Kind Regards,
> Sooyoung Eo
>
>
> 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:

[Ben Wilson]

This email closes public discussion and is notice that it is Mozilla’s
intent to approve NAVER's request for inclusion. (This starts a 7-day
period of last call for objections.)

On Mon, Nov 9, 2020 at 2:10 PM Ben Wilson <bwi...@mozilla.com> wrote:

> Step 6 of CA Application Process
> <https://wiki.mozilla.org/CA/Application_Process>: *Summary of
> Discussion and Resulting Decision:*
>
> One commenter stated that it appeared that a few certificates were
> misissued, i.e. that the stateOrProvinceName field (“S” field) should
> probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city. A
> NAVER representative responded that it had fixed the DN structure with L
> equal to "Seongnam-si" as city name and S field as "Gyeonggi-do" for

> province name. NAVER also added a procedure, in compliance with ISO
> 3166-2, to put province information correctly in the S field of user DN for
> newly issued certificates.
>

> On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Thank you all for the comments during the public discussion phase.
>> All matters raised in this public discussion has been fixed and then
>> published
>> our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14,
>> and 9.16.3.
>>
>> You can find the revised CPS v1.5.0 at our repository.
>> https://certificate.naver.com/bbs/initCrtfcJob.do
>> (directly download link:
>> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf
>> )
>>
>> To minimize confusion, I would like to metion that "NAVER BUSINESS
>> PLATFORM"
>> has been renamed to "NAVER Cloud" without any changes on the ownership of
>> the company and Certification Authority on October 26, 2020.
>>
>> Kind Regards,
>> Sooyoung Eo
>>
>>
>> 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용: