Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

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  wrote:

> Step 6 of 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

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Step 6 of 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 t

Re: NAVER: Public Discussion of Root Inclusion Request

[Sooyoung Eo via dev-security-policy]

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님이 작성한 내용:
> 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님이 작성한 내용:
> > > 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=0261
> >  
> > > > 
> > > > *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 
> > > > 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 

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

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-security-policy@lists.mozilla.org> wrote:

> 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 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=0261
> > >
> > > *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
> > > 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
>

Re: NAVER: Public Discussion of Root Inclusion Request

[Sooyoung Eo via dev-security-policy]

2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 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 
>  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=0261
> >  
> > 
> > *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
> > 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-certifi

Re: NAVER: Public Discussion of Root Inclusion Request

[Sooyoung Eo via dev-security-policy]

2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 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 
>  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=0261
> >  
> > 
> > *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
> > 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-certifi

Re: NAVER: Public Discussion of Root Inclusion Request

[Sooyoung Eo via dev-security-policy]

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

2020년 10월 22일 목요일 오전 3시 29분 40초 UTC+9에 Ryan Sleevi님이 작성한 내용:
> On Wed, Oct 21, 2020 at 2:09 PM Matthias van de Meent via 
> dev-security-policy  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. 
> 

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

On Wed, Oct 21, 2020 at 2:09 PM Matthias van de Meent via
dev-security-policy  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

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
 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=0261
>
> *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=

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

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

On Fri, Oct 9, 2020 at 4:30 PM George  wrote:

> 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-security-policy@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=0261
> >
> > *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
> > 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=c

Re: NAVER: Public Discussion of Root Inclusion Request

[George via dev-security-policy]

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 
 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=0261
>
> *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
> 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