1404221 - Add Root certificate of NAVER Business Platform

Status: RESOLVED FIXED

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

Description

[Han Yong, Park]

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

Steps to reproduce:

NAVER Business Platform, a private enterprise in South Korea, established its Root Certification Authority (Root CA) for issuing SSL certificates to our customers.
NAVER Business Platform officially apply our Root CA certificate inclusion to Mozilla products according to Mozilla Root Store Policy since 2017.


Actual results:

N/A. We will follow the Mozilla Root Store Policy.


Expected results:

N/A. We will follow the Mozilla Root Store Policy.

Comment 1

[Kathleen Wilson]

Mozilla's root inclusion process is intentionally very long and arduous, as described here:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Please see
https://wiki.mozilla.org/CA/Application_Process#Who_May_Apply
and explain why you think NAVER should have their root certificate directly included in Mozilla's root store, rather than have it be cross-signed by an already-included root certificate.

If you truly believe that NAVER should have their root certificate directly included in Mozilla's root store then please provide the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist

Comment 2

[Firefox Bug Husbandry Bot]

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

Comment 3

[Han Yong, Park]

Attachment: NAVER Business Platform_CA Information_Checklist.docx

Kathleen, 

We attached our CA Information Checklist according to your guidance.

Comment 4

[Han Yong, Park]

Attachment: NAVER BUSINESS PLATFORM_Certification Practice Statement_EN.PDF

CPS english version

Comment 5

[Han Yong, Park]

(In reply to Kathleen Wilson from comment #1)
> Mozilla's root inclusion process is intentionally very long and arduous, as
> described here:
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview
> 
> Please see
> https://wiki.mozilla.org/CA/Application_Process#Who_May_Apply
> and explain why you think NAVER should have their root certificate directly
> included in Mozilla's root store, rather than have it be cross-signed by an
> already-included root certificate.
> 
> If you truly believe that NAVER should have their root certificate directly
> included in Mozilla's root store then please provide the information listed
> here:
> https://wiki.mozilla.org/CA/Information_Checklist

Hi Kathleen, 

As you mentioned, NAVER BUSINESS PLATFORM has uploaded the CA_Information Checklist according to https://wiki.mozilla.org/CA/Information_Checklist. Also the English CPS has been attached to this thread. It would be appreciated if you check our CA Information and CPS and then let me know the next steps to proceed.

Comment 6

[Kathleen Wilson]

Acknowledging receipt of the information. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Comment 7

[Kathleen Wilson]

Attachment: naverrca1.crt

Comment 8

[Kathleen Wilson]

Attachment: 1404221-CA-Information-May23-2018.pdf

The attached document shows the information that has been verified for this request. Search the document for the word "NEED" to find where clarification or further information or testing is needed.

Items of note:

- No revision table found in CPS

- Allowed CAA domains not listed in CPS

- Reasons to revoke a certificate do not align with section 4.9.1.1 of the BRs.

- Not clear in CPS that DNS name must be in SAN.

- CPS needs to document cert validity periods, and be aligned with the current BRs.

- CPS unclear about CA providing key pairs for SSL certs.

- Unclear why NAVER needs to be directly included in a root store, rather than cross-signed by an already-included CA. The justification appears to be for their portal... If a CA controls all the domains that use their root certificate, then they probably do not meet the criteria for inclusion in Mozilla's root store. 

- Test websites did not work as expected.

- Revocation check errors, including "Certificate status is 'Good' expecting 'Unknown'"

- This root is not in found in crt.sh, so need to run the lint tests manually.

- The documentation in the CPS about the domain validation procedures is not informative enough to determine which of the allowed Domain Validation methods (per BR section 3.2.2.4) are used.

Comment 9

[Han Yong, Park]

Attachment: Test website screenshots.pdf

We updated screenshots on test website results.

Comment 10

[Han Yong, Park]

Attachment: NAVER Business Platform_Lint Test Results Report.pdf

Lint testing results on Root, Issuing CA, and subscriber certificates from the valid test website.

Comment 11

[Han Yong, Park]

(In reply to Kathleen Wilson from comment #8)
> Created attachment 8980127 [details]
> 1404221-CA-Information-May23-2018.pdf
> 

Thanks for your comments, Kathleen.

We, NAVER BUSINESS PLATFROM, are currently updating our CPS and the revised one will be published within a few weeks. We would like to express our compliance with CA/Browser Forum BRs and Mozilla Policy. Please review our response to your comments.

- No revision table found in CPS
There is no revision table on ‘NAVER BUSINESS PLATFORM Certification Practice Statement_EN.PDF’ since the document was initial. The CPS we’re updating would have a revision table.

- Allowed CAA domains not listed in CPS
We established procedures to check whether a requesting domain has its CAA domain(s). NAVER BUSINESS PLATFORM planned on registering the NBP’s CAA if we have an access authority to CCADB after our Root certificate inclusion into Mozilla and/or Microsoft. 

- Reasons to revoke a certificate do not align with section 4.9.1.1 of the BRs.
We are able to revoke a certificate within 24 hours if any of reasons listed on section 4.9.1.1 of CA/Browser Forum BRs as follow. 
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;
4. The CA obtains evidence that the Certificate was misused;
5. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
8. The CA is made aware of a material change in the information contained in the Certificate;
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
12. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).


- Not clear in CPS that DNS name must be in SAN.
Test pages prove that NBP CA issues certificates whose DNS name is in SAN. A DNS name in SAN is described in the CPS we’re updating.

- CPS needs to document cert validity periods, and be aligned with the current BRs.
On section 6.3.2, subscriber certificate’s validity is 1 year or 2 year. It means any certificate validity does not exceed 825 days. 

- CPS unclear about CA providing key pairs for SSL certs.
NBP CA does not generate any key pairs of subscribers for SSL certificates.   

- Unclear why NAVER needs to be directly included in a root store, rather than cross-signed by an already-included CA. The justification appears to be for their portal... If a CA controls all the domains that use their root certificate, then they probably do not meet the criteria for inclusion in Mozilla's root store. 
The NAVER Global Root CA is run by NAVER BUSINESS PLATFORM. NAVER secure CA is a commercial CA will issue SSL certificates to customers from around the world. Customers of NAVER secure CA are the general public. The certification services will be provided for users of NAVER portal services first but would be expanded externally after the Root certification inclusion into Mozilla products.

- Test websites did not work as expected.
We patched the bug. Attached please find the screenshots showing it works correctly. 

- Revocation check errors, including "Certificate status is 'Good' expecting 'Unknown'"
We patched the bug. 
https://certificate.revocationcheck.com/test1-certificate.naver.com


- This root is not in found in crt.sh, so need to run the lint tests manually.
We attached a manual lint-test results document on the root, issuing CA and subscriber certificates. Please see NBP Lint Test Results Report.


- The documentation in the CPS about the domain validation procedures is not informative enough to determine which of the allowed Domain Validation methods (per BR section 3.2.2.4) are used.
Our domain validation procedures are comply with section 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact of CA/Browser Forum BRs. We receive a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address identified as a Domain Contact. The Random Value SHALL be unique in each email. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.

Comment 12

[Kathleen Wilson]

(In reply to Han Yong, Park from comment #11)
> (In reply to Kathleen Wilson from comment #8)
> > Created attachment 8980127 [details]
> > 1404221-CA-Information-May23-2018.pdf
> > 
> 
> Thanks for your comments, Kathleen.
> 
> We, NAVER BUSINESS PLATFROM, are currently updating our CPS and the revised
> one will be published within a few weeks. We would like to express our
> compliance with CA/Browser Forum BRs and Mozilla Policy. Please review our
> response to your comments.
> 

Please add a comment to this bug when your updated CPS is available in English and on your website.
https://certificate.naver.com/bbs/initCrtfcJob.do

Comment 13

[Kathleen Wilson]

I'm still seeing errors here:
https://certificate.revocationcheck.com/test-certificate.naver.com

And the CA's BR Self Assessment (https://wiki.mozilla.org/CA/BR_Self-Assessment#Template) needs to be attached to this Bugzilla Bug.

Comment 14

[Han Yong, Park]

(In reply to Kathleen Wilson from comment #12)
> (In reply to Han Yong, Park from comment #11)
> > (In reply to Kathleen Wilson from comment #8)
> > > Created attachment 8980127 [details]
> > > 1404221-CA-Information-May23-2018.pdf
> > > 
> > 
> > Thanks for your comments, Kathleen.
> > 
> > We, NAVER BUSINESS PLATFROM, are currently updating our CPS and the revised
> > one will be published within a few weeks. We would like to express our
> > compliance with CA/Browser Forum BRs and Mozilla Policy. Please review our
> > response to your comments.
> > 
> 
> Please add a comment to this bug when your updated CPS is available in
> English and on your website.
> https://certificate.naver.com/bbs/initCrtfcJob.do

 

We, NAVER BUSINESS PLATFORM, have revised our CPS in English and the document is downloadable through the below link.

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b1f69d146f7f42109b3768099d821653.pdf&atch_real_file_nm=NBP_CPS_v1.1_EN.pdf

Comment 15

[Han Yong, Park]

(In reply to Kathleen Wilson from comment #13)
> I'm still seeing errors here:
> https://certificate.revocationcheck.com/test-certificate.naver.com
> 
> And the CA's BR Self Assessment
> (https://wiki.mozilla.org/CA/BR_Self-Assessment#Template) needs to be
> attached to this Bugzilla Bug.

We have issued the relevant CRLs so the bug has been fixed. NBP CA updates CRLs automatically every day according to section 2.3 of the CPS. I am writing the BR self-assessment document based on NBP CPS v1.1 (revised) then will upload the document soon.

Comment 16

[Kathleen Wilson]

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.

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

In particular:

1) Attach BR Self Assessment (https://wiki.mozilla.org/CA/BR_Self-Assessment) to this bug.

2) See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#DNS_names_go_in_SAN
NEED: CPS updated to make it clear that domain name goes in SAN. If CN is used, the domain in the CN must also be in the SAN.
CPS section 3.1.2 says: "The domain name to be included in the CN *or* SAN. 
and Appendix A, certificate profiles, does not mention SAN. 

3) NEED to resolve all errors: 
https://certificate.revocationcheck.com/test-certificate.naver.com 
- ERROR: Response expired 1206h9m32s ago 
http://rca.navercorp.com/arl/Arl1Dp1.crl 
This update: Aug 19, 2018 9:00:00 AM 
Next update: Sep 18, 2018 9:00:00 AM

Comment 17

[Han Yong, Park]

Thanks for your comments.

2. NEED: CPS updated to make it clear that domain name goes in SAN.

We have updated our CPS to make it clear. Please see section 3.1.2 of our revised CPS.
3.1.2 Need for Names to be Meaningful
The NAVER BUSINESS PLATFORM puts meaningful names in both the subjectDN and the issuerDN extensions of Certificates.

You can find SAN extension APPENDIX A : CERTIFICATE PROFILES of the CPS.

CPS url: https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=26d336c969414668a4dd177914b396d8.pdf&atch_real_file_nm=NBP_CPS_V1.3_ENGLISH.pdf

(In reply to Kathleen Wilson from comment #16)

The link below shows the CA information that has been verified. Search in
the page for the word "NEED" to see where further clarification is requested.

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

In particular:

1. Attach BR Self Assessment
   (https://wiki.mozilla.org/CA/BR_Self-Assessment) to this bug.

2. See
   https://wiki.mozilla.org/CA/
   Required_or_Recommended_Practices#DNS_names_go_in_SAN
   NEED: CPS updated to make it clear that domain name goes in SAN. If CN is
   used, the domain in the CN must also be in the SAN.
   CPS section 3.1.2 says: "The domain name to be included in the CN or SAN.
   and Appendix A, certificate profiles, does not mention SAN.

3. NEED to resolve all errors:
   https://certificate.revocationcheck.com/test-certificate.naver.com

• ERROR: Response expired 1206h9m32s ago
  http://rca.navercorp.com/arl/Arl1Dp1.crl
  This update: Aug 19, 2018 9:00:00 AM
  Next update: Sep 18, 2018 9:00:00 AM

Comment 18

[Han Yong, Park]

3. NEED to resolve all errors

We have resolved all errors you mentioned before.
https://certificate.revocationcheck.com/test-certificate.naver.com

(In reply to Kathleen Wilson from comment #16)

3. NEED to resolve all errors:
   https://certificate.revocationcheck.com/test-certificate.naver.com

• ERROR: Response expired 1206h9m32s ago
  http://rca.navercorp.com/arl/Arl1Dp1.crl
  This update: Aug 19, 2018 9:00:00 AM
  Next update: Sep 18, 2018 9:00:00 AM

Comment 19

[Han Yong, Park]

Attachment: NBP CPS BR Compliance Self Assessment.xlsx

I attached the BR Self Assessment on our current CPS. Please review the document to proceed.

(In reply to Kathleen Wilson from comment #16)

The link below shows the CA information that has been verified. Search in
the page for the word "NEED" to see where further clarification is requested.

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

In particular:

1. Attach BR Self Assessment
   (https://wiki.mozilla.org/CA/BR_Self-Assessment) to this bug.

Comment 20

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

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

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:

https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Comment 21

[Han Yong, Park]

(In reply to Kathleen Wilson from comment #20)

The information for this root inclusion request is available at the following URL.

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

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Hello Kathleen and Wayne,
We have been waiting for the detailed CPS review for 2 months. Could you let me know when we know the review results?

Comment 22

[Wayne Thayer]

I am the only person performing these reviews, and I currently have a large backlog: https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

Sorting by the date that the request entered my queue, yours is behind 6 others. I would estimate that it will be another 3-6 months before I am able to review it.

Comment 23

[Han Yong, Park]

Attachment: NAVER BUSINESS PLATFORM CPS v1.4 ENGLISH

We, NBP, attached the new CPS v1.4 updated in November 2019. Please use the document for CPS review. You can download the CPS on the official repository.

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=447cd9dda18f4cc684196618bda68245.pdf&atch_real_file_nm=NBP_CPS_V1.4_ENGLISH.pdf

Comment 24

[Han Yong, Park]

Hello Ryan and Wayne,

As Wayne said that it would take 3-6 months to review the NBP CPS, we, NBP, have been waiting for long but couldn’t get any response since July 2019.
Please review the CPS attached on January 14, 2020. Let me know the delay reason, how long we need to standby and when we can expect to complete the request.

Comment 25

[Ryan Sleevi]

As mentioned, there is a queue, which we have been working through. Different CAs go faster or slower depending on the number of issues found, whether or not the CA is or has been implementing good practices based on following the discussions here, and the degree of public discussion involved.

As a general rule, CAs that are prepared, thoroughly documented, and have reviewed and been following the CA incident and CP/CPS reviews for the past several years go much faster. So as you wait, it may be helpful to review the other CP/CPS reviews that happened, as well as other incidents, and update anything you feel would benefit from added clarity or shows those same root issues that were highlighted for others.

Comment 26

[Kathleen Wilson]

Han Yong, Would you please do the following three things?

1. Add records to the CCADB for each intermediate cert chaining up to this root.
   https://www.ccadb.org/cas/intermediates#adding-intermediate-certificate-data

2. Explain why the current audit statements were issued more than 93 days after the audit period end date
   (Audit period end date: November 30, 2019. Audit Statement date: April 28, 2020)

3. Explain and resolve the lint testing errors:
   https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

Comment 27

[Han Yong, Park]

Hello Kathleen, I reply to your comment as below. Please let me know if you have any further questions.

1. Add records to the CCADB for each intermediate cert chaining up to this root.
   https://www.ccadb.org/cas/intermediates#adding-intermediate-certificate-data

I added the PEM data for one intermediate certificate chaining up to the root.

2. Explain why the current audit statements were issued more than 93 days after the audit period end date
   (Audit period end date: November 30, 2019. Audit Statement date: April 28, 2020)

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.

3. Explain and resolve the lint testing errors:
   https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

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.

Comment 28

[Ryan Sleevi]

Attachment: # Naver CP/CPS Revie

Comment 29

[Ryan Sleevi]

I've completed my initial review, and I believe Ben's also completed a review that found a number of things that I've not noted here. I wanted to allow Ben to post his own findings.

My overall concern with the CP/CPS is that a number of things ended up in "meh" or "bad" largely because the CP/CPS lacked sufficient detail to have a good understanding of how NAVER is operating, and how NAVER has been following the ecosystem developments. A big question, with any new CA, is are we going to have a repeat of issues that have been previously addressed, either in the CA/Browser Forum or through Mozilla CA Communications, and are we going to see any of the trends we've seen in the incidents.

This may seem like a high bar for a new CA to overcome, but I think it's somewhat reflective of the fact that, for better or worse, with included CAs, we not only have their CP/CPS to lean on, but also past incident reports. The unfortunate sheer number of DigiCert incidents, for example, has given a fairly in-depth understanding about their processes. Similarly, the validation bugs we've seen from a number of CAs around OV has built up a rather extensive understanding about different CAs' approaches to validation, change control management, incident response, and other critical security functions.

As a new CA, I think our goal should be to try to meet that same level of understanding. So my big request is "I think we need more documentation". I think it's understandable for NAVER to ask "What documentation is appropriate", and I think spending a month or two reviewing all of the Mozilla CA Incidents in the past 2 years is actually a really good starting point. Unfortunately, this isn't an easy task, because of how many incidents there are, but I think it provides a lot of insight into the sort of questions we seek to understand, and the concerns that might exist with processes, controls, documentation. An "ideal CPS" is one that we can look at, and we can see clear demonstration of best practices that have been discussed, and clearer understanding about how the various challenging problem areas are addressed.

Again, while I realize this might seem like a double standard, I think it's worth mentioning that a number of CAs who have had incidents are at risk of themselves being distrusted, in part because of these incidents, and especially those that have failed to learn either from their past incidents or other CAs' incidents. So while we haven't held those CAs' CP/CPSes to the same standard, we have required the same degree of transparency from them, and unlike them, NAVER isn't working at a trust deficit (caused by issues) but from a blank slate.

I think this approach is likely useful for all future CP/CPS reviews, and is something I plan to call attention to going forward.

I'm setting N-I for Ben to share his own findings, as well as his thoughts about how confident he would be, having seen a number of incidents from other CAs, that judging by the CP/CPS alone, he could be confident that none of the confusion, oversight, or misimplementation issues we've seen will be present. Improving the CP/CPS, by doing a methodical review and classification of bugs and looking at the sort of questions asked about implementations, is the best way I can think to address those.

Naver CP/CPS Review

• Documents Reviewed: https://bug1404221.bmoattachments.org/attachment.cgi?id=9120971
• NAVER BUSINESS PLATFORM Corp. Certification Practice Statement V1.4

Good

• 1.1: A single document that captures both CP and CPS for the entire hierarchy, making it easier to review
• 1.3.1: does not cross-sign or otherwise allow externally operated sub-CAs
• 1.3.2: does not use RAs or, presumably, DTPs, based on the wording.
• 1.4.2: explicitly states "traffic management" and MITM are forbidden.
• 3.1.1: explicitly and completely lists which subject fields are present, and does not use streetAddress or postalCode
• 3.3: Re-key is explicitly called out as being the same as new issuance
• 4.4.3: Explicitly calls out logging to Certificate Transparency
• 4.6: Explicitly requires rekey on renewal, rather than reusing existing keys

Meh

• 1.2: The change history suggests that CAA information was not added until version 1.1, on 2018-09-10. However, the Baseline Requirements introduced this with Ballot 125, with an effective date of 2015-04-15. Ballot 187 modified this disclosure requirement, effective 2017-09-08, but it's unclear based on the change table whether or not it was complying with 125 or not.
  • Why the two year gap with this change?
  • Are previous versions available to see how well NAVER tracked other changes, both to the BRs and to root programs?
• 1.5.2: It's unclear if the contact provided is for questions about the CA or for the problem reporting mechanism, as required by Section 4.9.3 of the BRs.
• 3.1.4: It's unclear from the CP/CPS the validation processes involved with this name forms (e.g. how valid localities are determined, for example).
• 3.1.5: It's unclear whether or not it's possible for two distinct Subscribers to share the same subject name. In an RFC 3647 format, this is where the CA would be able to say how they handle if those name conflicts arise.
• 3.2.1: A key proof of posession is required, via CSR or "cryptographically requivalent," but this isn't necessarily needed for TLS certificates.
• 3.2.2.1: Describes what they "could" do, but it's unclear if that's actually what they actually do.
• 3.2.2.4.x: The supported validation methods are 3.2.2.4.2 and 3.2.2.4.4; these are documented as against v1.4.1 of the BRs, which is valid, but always a red flag to see older versions of the BRs mentioned
  • These methods don't really provide insight into how the CA implements these methods (e.g. for potential error prone interpretations or actions). This lack of detail is what otherwise prevents me from saying "Good" for not supporting error-prone validation methods.
• 3.2.2.6: Doesn't describe how public suffix/registry controlled is determined (e.g. process for determining, process for updating, if any overrides exist, etc)
• 3.2.4: Could be improved by explicitly stating that no non-verified information is present ("OU" is the complex exception)
• 3.2.5: Similar to much of the other feedback, doesn't document what the process is that the Applicant should use to specify how Applicants can specify the individuals to request certificates.
• 4.9.1.1: Has not been kept in sync with the BRs, which changed in SC6 (effective day 2018-10-14). Because the post-SC6 change is more permissive, this isn't a "bad"; if anything, keeping the more restrictive requirement is "good". It's "meh" because it's unclear if that's intentional, or an oversight in reviewing the BR changes.
• 5.2.4: Makes reference to Delegated Third Parties, despite earlier remarks, and doesn't make it clear whether/if single participants can occupy multiple roles/how that's managed.
• 5.4.4: Parses weird, in that it's unclear whether administrators can only view (their tasks') audit records, or whether they (can only view) their tasks' audit records. The former implying that they cannot view the tasks of others' records, while the latter implying that they cannot modify their tasks' audit records. I'm hoping for the latter, but a different way of rewording (e.g. "cannot modify") might help disambiguate if that's what is meant.
• 6.1.5: Only RSA keys are supported. EC keys would be nice for speed.
• 8.2: Only lists a subset of the requirements in BRs 8.2. This might mean "BRs apply because they're more specific", or it might mean "We're telling you what we do, and it's less than what the BRs require".

Bad

• 1.3.3: It's unclear if this is a translation issue, but it would appear NAVER only supports (Korean-based (individuals or entities)). It might have been meant as ((individuals) or (entities based in Korea)), but it's unclear how to parse the description.
• 3.2.2.4: Doesn't describe whether or not they reuse domain validation data, and if so, for how long, nor does it document that they maintain records of the validation method (and, ideally, how that information is maintained). I placed this as Bad, rather than Meh, because this is the only time we have for the CA to really document how they manage this in a binding way.
  • Notably, 4.2.1 just points back to 3.2, so it's unclear in either place where a discussion of data reuse might be discussed if/how that's handled.
• 3.4: States NAVER will notify relying parties prior to revocation. This was probably only meant to say notify the Subscriber, since revocation itself is the act of notifying relying parties. This was almost a "meh", because it might mean certificates with special use cases where NAVER knows who the RPs are, but that'd both benefit from explicitly stating so and probably be "bad" as an undesirable (not agile) dependency.
• 4.1.1: states the RA will verify "if the domain name is included in WHOIS or a trusted database accepted by the NAVER BUSINESS PLATFORM". It's the "or a trusted database" that raises a concern about whether or not this could be seen as bypassing domain control checks / bypassing ICP-3 by using some alternative domain system. I raise this as a "bad" to explicitly confirm the process of validating a domain in the authortative dataset is not skipped.
• 4.6.1: Limits renewal to 90 days before expiration. There doesn't seem any benefit in that stipulation, especially if they want a new cert sooner?
• 4.9.3: Missing one of the requirements from 4.9.5 of the BRs
• 4.9.6: Places requirements on Relying Parties that few (no?) relying parties implement.
• 4.9.7: A single CRL URL is documented in the CPS. It'd be better to leave the URL undocumented in the CP/CPS, in the event new intermediates are created and/or need to be created in the future, so as to not require a CP/CPS update or add complexity. Focusing on the update frequency/practices is sufficient.
• 4.9.9: Uses delegated responder certificates, which make for chunkier OCSP responses. A profile for the responder certificate is not provided in Appendix A, which is why this is "Bad" and not "meh" for just the fat responses.
• 7.1.4: Completely lacks information about the validation process for subscriber information. While ideally this information would be discussed within Section 3 (e.g. 3.1.1), there's not a clear binding between "these fields" and "validated information"
• 7.3: Awkwardly worded enough to warrant a "bad", it's unclear what the status is expected for certificates that violate the BRs. The way it's worded, it won't respond "Good", but it's unclear if that means "unknown", "revoked", or an unsigned response like "unauthorized". Two out of three can be interpreted as "not revoked", so maybe a reword is in order. I suspect this is trying to say it doesn't reply Good for certificates it does not have record of issuing (as discussed in Section 4.9.10 of the BRs), but that isn't clear.
• 9.4: Refers entirely to an external document, which means it's exempt from some of the change control/management processes of the CPS. Including as an Appendix is at least slightly better for making sure it's versioned and maintained, and if the privacy policy in the CPS vs the Website ever differed, that'd at least be a strong sign something was wrong.
• 9.5: Prohibits distribution of NAVER certificates as trust anchors (e.g. partial representation). The problematic language is asserting the Certificates as the exclusive property and can only be reproduced or distributed "in full", and prohibiting "derivative works". At fundamental question is whether or not a Certificate is a copyrightable concept, since it's a statement of a fact (like a phone number for a business), as opposed to a creative or transformative endeavor; it may be worth revisiting this section again entirely with your lawyers to think about this approach.
• 9.16.5: "The operation of the Internet is beyond The NAVER BUSINESS PLATFORM'S reasonable control.". It's unclear whether this is trying to Force Majeure itself out of any of the obligations found within the CP/CPS. For example, CAA check failed? "Outside reasonable control; force majeure applies and we decided to issue anyways". The extent of how big a get-out-of-obligation card this is raises serious questions.

Comment 30

[Ben Wilson]

I agree with all of Ryan's comments, especially that NAVER should familiarize itself with CA incidents over the past few years.
See https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&list_id=15316751&chfieldfrom=2018-06-01&resolution=---&resolution=FIXED&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&component=CA%20Certificate%20Compliance&chfield=bug_status&product=NSS

Here are my own additional comments, some of which are the same as Ryan's.

GOOD
1.1 Overview
Document was created in accordance with RFC 3647 and asserts conformity to current version of CA/Browser Forum Baseline Requirements.

1.2 Document Name and Identification
The CPS states it applies to the "NAVER Global Root Certification Authority" and the "NAVER Secure Certification Authority". This meets item 6 in section 3.3 of the Mozilla Root Store Policy (“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates”).
This section also contains table of revisions showing some degree of CPS change control in place.

1.4.2 Prohibited Certificate Uses
Section states, “Additionally, Certificates issued under this CPS may not be used for “traffic management” or man- in-the middle purposes.”

6.1.2 Private Key Delivery to Subscriber
NAVER does not generate subscriber Key Pairs. (Mozilla Root Store Policy 5.2)

6.5.1 Specific Computer Security Technical Requirements
Multi-Factor Authentication is implemented for all the accounts used for the lifecycle management of the certificates issued by the NAVER BUSINESS PLATFORM CA system. (Mozilla Root Store Policy 2.1)

MEH (Minor Issues)
1.3.2 Registration Authorities
This section says, “All the RA functions will be performed by the NAVER BUSINESS PLATFORM.” But it could be more explicit by adding, “and none will be delegated to third parties.”

1.3.3 Subscribers
Subscribers do not “issue” certificates. They “receive” certificates from the NAVER Secure CA. This wording in this section should be fixed.

1.3.4 Relying Parties
A relying party does not generate digital signatures with a digital certificate issued by NAVER. The wording in this section should be fixed.

1.6.1 Definitions
WebTrust - The current version of CPA Canada’s WebTrust Program for Certification Authorities.

1.6.2 Acronyms
CABF should be the acronym for the CA/Browser Forum (not CAB).

2.3 Time or Frequency of Publication
This section currently says, “Generally, the CRL is periodically updated and reissued at least every seven (7) days, and their validity period is limited to ten (10) days.” However, this is inconsistent with CPS section 4.9.7 (CRL Issuance Frequency) below, which says, “The CRL is published periodically at least every day and is valid for seven (7) days.” So, this sentence needs to be fixed.

3.1.1 Type of Names
NAVER should amend this section to state that its naming practices comply with RFC5280 and the CABF Baseline Requirements.

3.1.2 Need for Names to be Meaningful
The subjectDN and the issuerDN are not certificate “extensions” – they are certificate fields.

3.2.2 Authentication of Organization Identity
The following sentence needs to be rephrased- “It must be verified whether all the subject information that will contain the NAVER BUSINESS PLATFORM certificate applicant conforms to the requirements of this CPS and has been validated under this CPS in accordance with procedures.” Is it meant to say, “All subject information to be contained in a NAVER BUSINESS PLATFORM certificate shall conform to the requirements of this CPS and be validated in accordance with the procedures in this CPS.”?

3.2.4 Non-verified Subscriber Information
This section of the CPS says that there is “No Stipulation.” Mozilla Root Store Policy section 2.2 requires that all information must be verified. However, this section should at least say, “Only verified information is contained in certificates.” (See CPS section 7.1.4, which says, “Optional subfields in the subject of an SSL Certificate must either contain information verified by the NAVER BUSINESS PLATFORM or be left empty.”)

4.1.2 Enrollment Process and Responsibilities
This section says, “One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 3.3.1, …” Yet section 3.3.1 is empty because it contains a cross-reference to section 3.2. I think the intent was to reference section 3.2.2.7 (Data Source Accuracy and Validity Periods). If so, then that change should be made.

4.2.4 Certificate Authority Authorization (CAA) Records
The reference to RFC 6844 should be replaced with a reference to RFC 8659.

4.9.8 Maximum Latency for CRLs
This section states, “The CRL is posted to the CRL repository within one (1) business day following the CRL generation.” That seems like a long time to post an updated CRL.

5.4.8 Vulnerability Assessments
This section states, “The NAVER BUSINESS PLATFORM periodically conducts its own scan to ensure effective security management in performing certification services.” The CABF’s Network and Certificate System Security Requirements require internal and external vulnerability scans every three months and an annual penetration test.

5.7.3 Entity Private Key Compromise Procedures
NAVER should add a provision that it will immediately notify Application Software Suppliers in the event of a CA private key compromise.

6.7 Network Security Controls
Please reference compliance with the CABF’s Network and Certificate System Security Requirements.

BAD (Major Issues)
1.1 Overview
NAVER needs to add the following sentence to this section: “In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this document.”

1.5.2 Contact Person
This section needs to include detailed information and instructions for filing certificate problem reports and for making revocation requests. Section 4.9.3 of the CABF Baseline Requirements says, “The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

1.5.4 CPS Approval Procedures
When visiting https://certificate.naver.com, one is redirected here https://certificate.naver.com/rootca/rootCaMain.do, and this CPS is not posted there as indicated.

2.3 Time or Frequency of Publication
NAVER should state that it will amend and publish a new version of the CPS annually regardless of whether any changes are needed. (Still, NAVER should continue to update its CPS “as needed to the latest version of the CA Browser Forum Baseline Requirements”.)

3.4 Identification and Authentication for Revocation Request
The following sentence causes some concern: “Prior to certificate revocation, the NAVER BUSINESS PLATFORM CA and RAs will notify the relying parties, including the subscribers, of the certificate revocation.” How and why will NAVER notify relying parties prior to certificate revocation? This sentence should be amended to remove the requirement that NAVER give prior notice before revocation.

4.9.2 Who Can Request Revocation
This sentence --“The process MUST be described in the CA’s Certificate Policy or Certification Practice Statement” itself means that NAVER MUST describe its revocation process more thoroughly in this CPS. (And then this sentence can be deleted.)

4.9.3 Procedure for Revocation Request
The following procedure is inadequate: “4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel begin investigating the request within 24 hours after receipt”. The reason is because section 4.9.5 of the CABF Baseline Requirements states, “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.” That means revocation must occur within 24 hours, not that investigation must begin within 24 hours.

4.9.5 Time Within Which CA Must Process the Revocation Request
This section is inadequate. See comments made under section 4.9.3 above. NAVER must begin to investigate a revocation request immediately and publish a new CRL within 24 hours.

5.4.2 Frequency of Processing Log
The following sentence is too vague “Audit logs are periodically reviewed by the NAVER BUSINESS PLATFORM on an as-needed basis.” Section 3.e. of the CABF Network and Certificate System Security Requirements (https://cabforum.org/network-security-requirements/) states, “[The CA SHALL] Monitor the integrity of the logging processes for application and system logs through continuous automated monitoring and alerting or through a human review to ensure that logging and log-integrity functions are effective. Alternatively, if a human review is utilized and the system is online, the process must be performed at least once every 31 days.”

Comment 31

[Han Yong, Park]

Thank you for the CPS review.
We are now reviewing the CPS comments written by Ryan and Ben. I will leave our response on some of the comments with explanations in a few days.

Comment 32

[Han Yong, Park]

NBP has reviewed the CPS review feedback and is going to revise NBP CPS within 2 weeks.

There are answers to some of comments on the CP/CPS review posts written by Ryan and Ben as of July 2020. If it’s okay, we will reflect the below information to CPS.

1.2 Document Name and Identification
NBP had designed the CA systems in 2017 and developed all components related to SSL certificates in 2018. CAA records has been working since 2017.

3.2.2.1 Identity
For OV certificates, business registration certificates issued by the Government of Korea and/or DUNS numbers submitted from applicants are used as validation methods.

3.2.2.4 Validation of Domain Authorization or Control
NBP doesn’t’t reuse domain validation data.

4.2.4 Certificate Authority Authorization (CAA) Records
NBP checks for a CAA record for each dNSName in the subjectAltName extension of the Certificate to be issued, according to the procedure in RFC 6844 according to CA Browser Forum BRs v1.7.0.

4.6.1 Circumstances for Certificate Renewal
That a subscriber can request a renewal of a certificate from ninety (90) days before the expiration date of the issued certificate means that a renewal notification is given to the subscriber 90 days before expiration. The certificate can be renewed earlier than the notification date.

6.1.5 Key Sizes
Only RSA keys are supported as of July 2020.

8.2 Identity/Qualifications of Assessor
NBP only adopts WebTrust audits and has annual audits since 2018.

Comment 33

[Han Yong, Park]

Attachment: NAVER BUSINESS PLATFORM CPS v1.4.1 ENGLISH

We have updated our CPS adjusted upon the comments of the CP/CPS review. You can find and download the new CPS v1.4.1 at our repository.

• Download URL: https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=e2a08f6d5d4245a685a12dea75456647.pdf&atch_real_file_nm=NBP_CPS_v1.4.1_EN.pdf

Comment 34

[Ben Wilson]

Naver CP/CPS - Second Review

I went through Ryan's comment #29 and my comment #30 and then through the CPS v. 1.4.1 to see how our comments were addressed.

• Documents Reviewed: https://bugzilla.mozilla.org/attachment.cgi?id=9166191
• NAVER BUSINESS PLATFORM Corp. Certification Practice Statement V1.4.1

Ryan's Original Comments and Ben's review of NAVER's CPS v.1.4.1

Meh

• 1.2: The change history suggests that CAA information was not added until version 1.1, on 2018-09-10. However, the Baseline Requirements introduced this with Ballot 125, with an effective date of 2015-04-15. Ballot 187 modified this disclosure requirement, effective 2017-09-08, but it's unclear based on the change table whether or not it was complying with 125 or not.
  • Why the two year gap with this change?
  • Are previous versions available to see how well NAVER tracked other changes, both to the BRs and to root programs?

These specific questions weren't answered, however the change history was moved to Appendix B with a much better description of the changes made in this latest version, v. 1.4.1.

• 1.5.2: It's unclear if the contact provided is for questions about the CA or for the problem reporting mechanism, as required by Section 4.9.3 of the BRs.

Language added: "for cases including, but not limited to, security issues such as reporting weaknesses, requests for certification revocation related to CA services, suspected key damage, misuse and improper use of certificates ..." with the problem-reporting email address.

• 3.1.4: It's unclear from the CP/CPS the validation processes involved with this name forms (e.g. how valid localities are determined, for example).

It appears that the only reference in the CPS that describes NAVER's process for verifying geographic locations is in section 3.2.2.1, which is still too brief to determine whether NAVER has adequately engineered processes for including locality and other OV-related information. For example, is NAVER aware of the various bugs in Bugzilla for CAs that have made errors in populating location information: see Bug #1648997, Bug #1575880, Bug #1613334, Bug #1653284, Bug#1645686, Bug#1644936, Bug #1551372, Bug #1551362, etc?

• 3.1.5: It's unclear whether or not it's possible for two distinct Subscribers to share the same subject name. In an RFC 3647 format, this is where the CA would be able to say how they handle if those name conflicts arise.

This section of the CPS has been amended to add "NAVER BUSINESS PLATFORM complies with the uniqueness of domain names of the server security certificate controlled by ICANN." However, it also provides that "NAVER BUSINESS PLATFORM does not, in general, enforce uniqueness of subject names," which is slightly confusing. NAVER could have made this more clear by stating that name uniqueness is enforced through the domain name system controlled by ICANN and that any FQDN in a Common Name must also appear in a Subject Alternative Name in the certificate that has been verified in accordance with section 3.2.2.4.

• 3.2.1: A key proof of possession is required, via CSR or "cryptographically equivalent," but this isn't necessarily needed for TLS certificates.

CPS amended to say that certificate applicants "normally" prove key ownership.

• 3.2.2.1: Describes what they "could" do, but it's unclear if that's actually what they actually do.

No substantive changes made to this section.

• 3.2.2.4.x: The supported validation methods are 3.2.2.4.2 and 3.2.2.4.4; these are documented as against v1.4.1 of the BRs, which is valid, but always a red flag to see older versions of the BRs mentioned
  • These methods don't really provide insight into how the CA implements these methods (e.g. for potential error prone interpretations or actions). This lack of detail is what otherwise prevents me from saying "Good" for not supporting error-prone validation methods.

Specific references to "v.1.4.1" of the Baseline Requirements has been removed.

• 3.2.2.6: Doesn't describe how public suffix/registry controlled is determined (e.g. process for determining, process for updating, if any overrides exist, etc)

Language added: "NAVER BUSINESS PLATFORM refers to the "public suffix list" of http://publicsuffix.org/ (PSL) as the judgment criterion, and periodically checks and reflects PSL updates."

• 3.2.4: Could be improved by explicitly stating that no non-verified information is present ("OU" is the complex exception)

CPS now states, "Only verified information is contained in certificates. Optional subfields in the subject of an SSL Certificate must either contain information verified by NAVER BUSINESS PLATFORM or be left empty."

• 3.2.5: Similar to much of the other feedback, doesn't document what the process is that the Applicant should use to specify how Applicants can specify the individuals to request certificates.

CPS now states that the CA only accepts certificate requests "from individuals verified through reliable methods of communication. Among verified individuals, NAVER BUSINESS PLATFORM may only accept Certificate requests from individuals with written designation by the Applicant to request for Certificates."

• 4.9.1.1: Has not been kept in sync with the BRs, which changed in SC6 (effective day 2018-10-14). Because the post-SC6 change is more permissive, this isn't a "bad"; if anything, keeping the more restrictive requirement is "good". It's "meh" because it's unclear if that's intentional, or an oversight in reviewing the BR changes.

Section 4.9.1.1 is now updated and consistent with section 4.9.1.1 of the Baseline Requirements.

• 5.2.4: Makes reference to Delegated Third Parties, despite earlier remarks, and doesn't make it clear whether/if single participants can occupy multiple roles/how that's managed.

Language added: "The Executive Officer, Internal Auditors, System Engineers / System Operators do not perform other trusted role tasks. The Policy Managers and Validation Specialists do not perform certificate management or registration management tasks."

• 5.4.4: Parses weird, in that it's unclear whether administrators can only view (their tasks') audit records, or whether they (can only view) their tasks' audit records. The former implying that they cannot view the tasks of others' records, while the latter implying that they cannot modify their tasks' audit records. I'm hoping for the latter, but a different way of rewording (e.g. "cannot modify") might help disambiguate if that's what is meant.

Section 5.4.4 has been modified to read, "The audit records generated by each system are managed by the personnel designated by NAVER BUSINESS PLATFORM, and only the administrators and internal auditors can view and search the audit records generated by each system. The generated audit records are not allowed to be modified. It is designed to break the data integrity of audit records when someone attempt to modify them."

• 6.1.5: Only RSA keys are supported. EC keys would be nice for speed.

No changes made.

• 8.2: Only lists a subset of the requirements in BRs 8.2. This might mean "BRs apply because they're more specific", or it might mean "We're telling you what we do, and it's less than what the BRs require".

Section 8.4 of the CPS also references the CA/B Forum's Baseline Requirements.

Bad

• 1.3.3: It's unclear if this is a translation issue, but it would appear NAVER only supports (Korean-based (individuals or entities)). It might have been meant as ((individuals) or (entities based in Korea)), but it's unclear how to parse the description.

The language has been clarified somewhat by removing the first reference to Korea such that it is clearer that certificates can be issued to subscribers within and outside of Korea.

• 3.2.2.4: Doesn't describe whether or not they reuse domain validation data, and if so, for how long, nor does it document that they maintain records of the validation method (and, ideally, how that information is maintained). I placed this as Bad, rather than Meh, because this is the only time we have for the CA to really document how they manage this in a binding way.
  • Notably, 4.2.1 just points back to 3.2, so it's unclear in either place where a discussion of data reuse might be discussed if/how that's handled.

NAVER states in Comment #32 "NBP doesn’t reuse domain validation data".

However, section 3.2.2.7 sets forth an 825-day period for which re-validation is required. This should be changed because (and NAVER should be on alert that) the certificate lifetime for SSL/TLS server certificates will soon be a 397-day maximum validity period. Section 6.3.2 of the CPS will also need to be amended.

• 3.4: States NAVER will notify relying parties prior to revocation. This was probably only meant to say notify the Subscriber, since revocation itself is the act of notifying relying parties. This was almost a "meh", because it might mean certificates with special use cases where NAVER knows who the RPs are, but that'd both benefit from explicitly stating so and probably be "bad" as an undesirable (not agile) dependency.

See Ben's original comment and NAVER's response below.

• 4.1.1: states the RA will verify "if the domain name is included in WHOIS or a trusted database accepted by the NAVER BUSINESS PLATFORM". It's the "or a trusted database" that raises a concern about whether or not this could be seen as bypassing domain control checks / bypassing ICP-3 by using some alternative domain system. I raise this as a "bad" to explicitly confirm the process of validating a domain in the authoritative dataset is not skipped.

The word "or" has been replaced with "and" so that a check of WHOIS is required. Note that this does not obviate the need to comply with and perform one of the required methods of domain validation set forth in Section 3.2.2.4 of the Baseline Requirements.

• 4.6.1: Limits renewal to 90 days before expiration. There doesn't seem any benefit in that stipulation, especially if they want a new cert sooner?

A comma has been added along with a phrase that makes it more clear that the subscriber can request renewal of the certificate (not limited) and that they are notified 90 days before expiration.

• 4.9.3: Missing one of the requirements from 4.9.5 of the BRs

"The consequences of revocation" added to this section.

• 4.9.6: Places requirements on Relying Parties that few (no?) relying parties implement.

I am not sure that it was the intent of Ryan's comment, but additional certificate-checking language was added. "Relying Parties are required to confirm the validity of each certificate in the certificate chain by checking for certificate validity, issuer to subject name chaining, policy and key use constraints and revocation status through CRL or OCSP responder before relying on a certificate."

• 4.9.7: A single CRL URL is documented in the CPS. It'd be better to leave the URL undocumented in the CP/CPS, in the event new intermediates are created and/or need to be created in the future, so as to not require a CP/CPS update or add complexity. Focusing on the update frequency/practices is sufficient.

Fixed.

• 4.9.9: Uses delegated responder certificates, which make for chunkier OCSP responses. A profile for the responder certificate is not provided in Appendix A, which is why this is "Bad" and not "meh" for just the fat responses.

Section now states, "OCSP Responder Certificate profile is included in Appendix A."

• 7.1.4: Completely lacks information about the validation process for subscriber information. While ideally this information would be discussed within Section 3 (e.g. 3.1.1), there's not a clear binding between "these fields" and "validated information"

Section 7.1.4.2 added which contains language concerning inclusion of a Domain Name or IP Address in a subject attribute. However, section 3.2.2.5 states that NAVER would not be issuing certificates to IP addresses.

• 7.3: Awkwardly worded enough to warrant a "bad", it's unclear what the status is expected for certificates that violate the BRs. The way it's worded, it won't respond "Good", but it's unclear if that means "unknown", "revoked", or an unsigned response like "unauthorized". Two out of three can be interpreted as "not revoked", so maybe a reword is in order. I suspect this is trying to say it doesn't reply Good for certificates it does not have record of issuing (as discussed in Section 4.9.10 of the BRs), but that isn't clear.

Section 7.3 has been amended to state that OCSP "does respond with a "Unknown" value on certificates, which have not been issued in compliance with the CA Browser Forum's Baseline Requirements." I believe that this wording is more confusing than what was originally there. The rule is that the CA cannot respond "Good" to a certificate that the CA is unaware of having issued. If the OCSP responder always responds "unknown" in those situations, then that is helpful to know, but I think the CPS should say that the OCSP responder does not respond with a "Good" for a certificate that it has no record of issuing.

• 9.4: Refers entirely to an external document, which means it's exempt from some of the change control/management processes of the CPS. Including as an Appendix is at least slightly better for making sure it's versioned and maintained, and if the privacy policy in the CPS vs the Website ever differed, that'd at least be a strong sign something was wrong.

A URL reference to the Privacy Policy has been provided.

• 9.5: Prohibits distribution of NAVER certificates as trust anchors (e.g. partial representation). The problematic language is asserting the Certificates as the exclusive property and can only be reproduced or distributed "in full", and prohibiting "derivative works". At fundamental question is whether or not a Certificate is a copyrightable concept, since it's a statement of a fact (like a phone number for a business), as opposed to a creative or transformative endeavor; it may be worth revisiting this section again entirely with your lawyers to think about this approach.

Section 9.5.1 has been amended and the following language has been deleted: "The NAVER BUSINESS PLATFORM grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full."

• 9.16.5: "The operation of the Internet is beyond The NAVER BUSINESS PLATFORM'S reasonable control.". It's unclear whether this is trying to Force Majeure itself out of any of the obligations found within the CP/CPS. For example, CAA check failed? "Outside reasonable control; force majeure applies and we decided to issue anyways". The extent of how big a get-out-of-obligation card this is raises serious questions.

The language in this section has been rewritten to shield NAVER from liability for delays or failures "caused by natural disasters, acts of war, terrorism or any other similar cause beyond the reasonable control of NAVER BUSINESS PLATFORM."

Ben's Comments

MEH (Minor Issues)
1.3.2 Registration Authorities
This section says, “All the RA functions will be performed by the NAVER BUSINESS PLATFORM.” But it could be more explicit by adding, “and none will be delegated to third parties.”

Language added that no RA functions will be delegated. This is good.

1.3.3 Subscribers
Subscribers do not “issue” certificates. They “receive” certificates from the NAVER Secure CA. This wording in this section should be fixed.

Fixed

1.3.4 Relying Parties
A relying party does not generate digital signatures with a digital certificate issued by NAVER. The wording in this section should be fixed.

Language regarding signature generation deleted.

1.6.1 Definitions
WebTrust - The current version of CPA Canada’s WebTrust Program for Certification Authorities.

Fixed

1.6.2 Acronyms
CABF should be the acronym for the CA/Browser Forum (not CAB).

Fixed

2.3 Time or Frequency of Publication
This section currently says, “Generally, the CRL is periodically updated and reissued at least every seven (7) days, and their validity period is limited to ten (10) days.” However, this is inconsistent with CPS section 4.9.7 (CRL Issuance Frequency) below, which says, “The CRL is published periodically at least every day and is valid for seven (7) days.” So, this sentence needs to be fixed.

This sentence has been fixed so that it is consistent.

3.1.1 Type of Names
NAVER should amend this section to state that its naming practices comply with RFC5280 and the CABF Baseline Requirements.

CPS makes minor clarifications.

3.1.2 Need for Names to be Meaningful
The subjectDN and the issuerDN are not certificate “extensions” – they are certificate fields.

Fixed

3.2.2 Authentication of Organization Identity
The following sentence needs to be rephrased- “It must be verified whether all the subject information that will contain the NAVER BUSINESS PLATFORM certificate applicant conforms to the requirements of this CPS and has been validated under this CPS in accordance with procedures.” Is it meant to say, “All subject information to be contained in a NAVER BUSINESS PLATFORM certificate shall conform to the requirements of this CPS and be validated in accordance with the procedures in this CPS.”?

This sentence has been fixed.

3.2.4 Non-verified Subscriber Information
This section of the CPS says that there is “No Stipulation.” Mozilla Root Store Policy section 2.2 requires that all information must be verified. However, this section should at least say, “Only verified information is contained in certificates.” (See CPS section 7.1.4, which says, “Optional subfields in the subject of an SSL Certificate must either contain information verified by the NAVER BUSINESS PLATFORM or be left empty.”)

CPS now states, "Only verified information is contained in certificates. Optional subfields in the subject of an SSL Certificate must either contain information verified by NAVER BUSINESS PLATFORM or be left empty."

4.1.2 Enrollment Process and Responsibilities
This section says, “One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 3.3.1, …” Yet section 3.3.1 is empty because it contains a cross-reference to section 3.2. I think the intent was to reference section 3.2.2.7 (Data Source Accuracy and Validity Periods). If so, then that change should be made.

"subject to the aging and updating requirement in Section 3.3.1" has been deleted

4.2.4 Certificate Authority Authorization (CAA) Records
The reference to RFC 6844 should be replaced with a reference to RFC 8659.

Still references RFC 6844, which might be an oversight.

4.9.8 Maximum Latency for CRLs
This section states, “The CRL is posted to the CRL repository within one (1) business day following the CRL generation.” That seems like a long time to post an updated CRL.

Section 2.3 has been amended to provide that revocation occurs within one day, the CRL is updated daily, and that it is valid for 7 days.

5.4.8 Vulnerability Assessments
This section states, “The NAVER BUSINESS PLATFORM periodically conducts its own scan to ensure effective security management in performing certification services.” The CABF’s Network and Certificate System Security Requirements require internal and external vulnerability scans every three months and an annual penetration test.

This is OK.

5.7.3 Entity Private Key Compromise Procedures
NAVER should add a provision that it will immediately notify Application Software Suppliers in the event of a CA private key compromise.

The following sentence was added, "If a Root CA private key is compromised, NAVER BUSINESS PLATFORM will inform browser vendors of the compromise and best estimate of the date of compromise."

6.7 Network Security Controls
Please reference compliance with the CABF’s Network and Certificate System Security Requirements.

Sections of the CABF’s Network and Certificate System Security Requirements have been incorporated into section 6.7 of the CPS.

BAD (Major Issues)
1.1 Overview
NAVER needs to add the following sentence to this section: “In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this document.”

The following has been added, "In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this document."

1.5.2 Contact Person
This section needs to include detailed information and instructions for filing certificate problem reports and for making revocation requests. Section 4.9.3 of the CABF Baseline Requirements says, “The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

See Ryan's original comment and NAVER's CPS amendment, discussed above.

1.5.4 CPS Approval Procedures
When visiting https://certificate.naver.com, one is redirected here https://certificate.naver.com/rootca/rootCaMain.do, and this CPS is not posted there as indicated.

URL is fixed.

2.3 Time or Frequency of Publication
NAVER should state that it will amend and publish a new version of the CPS annually regardless of whether any changes are needed. (Still, NAVER should continue to update its CPS “as needed to the latest version of the CA Browser Forum Baseline Requirements”.)

CPS language updated to say that it is updated annually, regardless of any changes, and that it is updated to meet the latest version of the CABF Baseline Requirements.

3.4 Identification and Authentication for Revocation Request
The following sentence causes some concern: “Prior to certificate revocation, the NAVER BUSINESS PLATFORM CA and RAs will notify the relying parties, including the subscribers, of the certificate revocation.” How and why will NAVER notify relying parties prior to certificate revocation? This sentence should be amended to remove the requirement that NAVER give prior notice before revocation.

Language concerning pre-revocation notification to relying parties has been removed.

4.9.2 Who Can Request Revocation
This sentence --“The process MUST be described in the CA’s Certificate Policy or Certification Practice Statement” itself means that NAVER MUST describe its revocation process more thoroughly in this CPS. (And then this sentence can be deleted.)

This language was removed. Procedure is described in Section 4.9.3.

4.9.3 Procedure for Revocation Request
The following procedure is inadequate: “4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel begin investigating the request within 24 hours after receipt”. The reason is because section 4.9.5 of the CABF Baseline Requirements states, “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.” That means revocation must occur within 24 hours, not that investigation must begin within 24 hours.

Fixed.

4.9.5 Time Within Which CA Must Process the Revocation Request
This section is inadequate. See comments made under section 4.9.3 above. NAVER must begin to investigate a revocation request immediately and publish a new CRL within 24 hours.

Fixed.

5.4.2 Frequency of Processing Log
The following sentence is too vague “Audit logs are periodically reviewed by the NAVER BUSINESS PLATFORM on an as-needed basis.” Section 3.e. of the CABF Network and Certificate System Security Requirements (https://cabforum.org/network-security-requirements/) states, “[The CA SHALL] Monitor the integrity of the logging processes for application and system logs through continuous automated monitoring and alerting or through a human review to ensure that logging and log-integrity functions are effective. Alternatively, if a human review is utilized and the system is online, the process must be performed at least once every 31 days.”

Language added: "CA systems capable of continuous automated monitoring and alerting use this function to check log processing and log integrity and automatically receive reports. For systems where continuous automated monitoring and alerting is not possible, human review of log processing and log integrity is performed every month."

Comment 35

[Han Yong, Park]

NBP has been reviewing Ben’s comments on NBP CPS v1.4.1. Thank you for the detailed comments. We will reflect the feedback then update the revised CPS within 2 weeks.

Comment 36

[Han Yong, Park]

Attachment: NAVER BUSINESS PLATFORM CPS v1.4.2 ENGLISH

Response to CP/CPS Second Review

NBP CPS has been revised upon Ben’s Comment #34 of the CP/CPS second review. I have attached the CPS v1.4.2. You can also find the revised CPS at the NBP CA’s repository. I believe all most of issues raised from Ben’s review have become clear through this CPS revision. Please see my below response to a few remained issues of them.

Ryan's Original Comments and Ben's review of NAVER's CPS v.1.4.1

Meh

1.2: The change history suggests that CAA information was not added until version 1.1, on 2018-09-10. However, the Baseline Requirements introduced this with Ballot 125, with an effective date of 2015-04-15. Ballot 187 modified this disclosure requirement, effective 2017-09-08, but it's unclear based on the change table whether or not it was complying with 125 or not.
Why the two year gap with this change?
Are previous versions available to see how well NAVER tracked other changes, both to the BRs and to root programs?

These specific questions weren't answered, however the change history was moved to Appendix B with a much better description of the changes made in this latest version, v. 1.4.1.

NBP had designed the NBP CA structure in 2017 then developed PKI systems related to SSL certificates in 2018. As Ben mentioned in second review, NBP had added Appendix B for description of the changes since version 1.4.1.

6.1.5: Only RSA keys are supported. EC keys would be nice for speed.

No changes made.

Only RSA keys are supported as of August 2020.

Bad

3.2.2.4: Doesn't describe whether or not they reuse domain validation data, and if so, for how long, nor does it document that they maintain records of the validation method (and, ideally, how that information is maintained). I placed this as Bad, rather than Meh, because this is the only time we have for the CA to really document how they manage this in a binding way.
Notably, 4.2.1 just points back to 3.2, so it's unclear in either place where a discussion of data reuse might be discussed if/how that's handled.

NAVER states in Comment #32 "NBP doesn’t reuse domain validation data".
However, section 3.2.2.7 sets forth an 825-day period for which re-validation is required. This should be changed because (and NAVER should be on alert that) the certificate lifetime for SSL/TLS server certificates will soon be a 397-day maximum validity period. Section 6.3.2 of the CPS will also need to be amended.

NBP reflected 397-day maximum validity period on Section 3.2.2.7 and Section 6.3.2 in CPS v1.4.2. What NBP intended in Comment #32 was the domain validation data (such as WHOIS emails and administrative emails verification result) only used in once. Subscribers are required to prove the ownership and control of the requested domain(s) whenever they request certificate application.

Comment 37

[Ben Wilson]

Could you look into a couple of CRL provisioning errors?

When I run this test - https://certificate.revocationcheck.com/test-certificate.naver.com I get the following warnings for the CRLs
http://ica.navercorp.com/crl/Crl1p1Dp1.crl and http://rca.navercorp.com/arl/Arl1Dp1.crl:

WARNING: Last-Modified header is not the same as ThisUpdate (RFC 5019, section 6.2)
WARNING: Expires cache header not set (RFC 5019, section 6.2)

Thanks,
Ben

Comment 38

[Ryan Sleevi]

Looking at the latest document, from Comment #36, I still see answers from Comment #32 not reflected in the CP/CPS. Considering that the CP/CPS is authoritative, the goal here is to ensure that any relevant answers from Comment #32 are indeed reflected in the CP/CPS.

I probably need to generate a PDF redline between these versions, to check what else changed, but a few comments below.

(In reply to Ben Wilson from comment #34)

• 3.2.2.1: Describes what they "could" do, but it's unclear if that's actually what they actually do.

No substantive changes made to this section.

Combined with the answer from Comment #32 (the use of DUNS), I'm concerned about this, because we've seen quality control issues re: DUNS and addresses. However, this is a broader issue with CAs, and more in line with the set of problems that CA/B Forum Ballot SC30 is trying to address (although that is presently just limited to EV).

I would encourage NAVER to add specific details here about the steps taken to validate identity and sources used (including listing DUNS)

• 3.2.2.4: Doesn't describe whether or not they reuse domain validation data, and if so, for how long, nor does it document that they maintain records of the validation method (and, ideally, how that information is maintained). I placed this as Bad, rather than Meh, because this is the only time we have for the CA to really document how they manage this in a binding way.
  • Notably, 4.2.1 just points back to 3.2, so it's unclear in either place where a discussion of data reuse might be discussed if/how that's handled.

NAVER states in Comment #32 "NBP doesn’t reuse domain validation data".

However, section 3.2.2.7 sets forth an 825-day period for which re-validation is required. This should be changed because (and NAVER should be on alert that) the certificate lifetime for SSL/TLS server certificates will soon be a 397-day maximum validity period. Section 6.3.2 of the CPS will also need to be amended.

Sure, but as it stands today, the conspicuous lack of saying something (e.g. what was said in Comment #32) is a bit troubling. I think it's useful here to capture (in 3.2.2.7) that domains are validated no more than X days prior to issuance of a certificate. I assume there's some delta X between validation and the actual issuance of the certificate, whether it be one second or one year, so specifying that is useful.

As written, 3.2.2.7 could be read that "Authority of Applicant" is the domain validation, which I don't think is the intent?

The solution here is to be explicit within the CP/CPS how DNS reuse and revalidation is handled

• 4.9.9: Uses delegated responder certificates, which make for chunkier OCSP responses. A profile for the responder certificate is not provided in Appendix A, which is why this is "Bad" and not "meh" for just the fat responses.

Section now states, "OCSP Responder Certificate profile is included in Appendix A."

The profile omits the mandatory id-pkix-ocsp-nocheck extension that has been the subject of much discussion on m.d.s.p. and on many CA incidents. This should be included in the Profile.

However, also concerning is that the validity period for OCSP responder certificates is quite large (in this case, approximately 2 years). This is somewhat inconsistent with https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1 and thus still under the BAD list. Because nocheck is required, OCSP responders should be kept short-lived (e.g. 30 - 90 days) to reduce risk, because it's effectively as bad as a CA compromise.

• 9.5: Prohibits distribution of NAVER certificates as trust anchors (e.g. partial representation). The problematic language is asserting the Certificates as the exclusive property and can only be reproduced or distributed "in full", and prohibiting "derivative works". At fundamental question is whether or not a Certificate is a copyrightable concept, since it's a statement of a fact (like a phone number for a business), as opposed to a creative or transformative endeavor; it may be worth revisiting this section again entirely with your lawyers to think about this approach.

Section 9.5.1 has been amended and the following language has been deleted: "The NAVER BUSINESS PLATFORM grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full."

I'm not seeing that in 9.5.1 of v1.4.2 attached in Comment #36.

But to clarify this more: It would be better to make it clear that NBP is not asserting property rights on the certificates it produces, period. If I'm developing, say, an embedded application, I may only have memory to store a DN and a public key (e.g. BearSSL and other embedded SSL libraries often implement root stores via this). In one perspective, that's a derivative work of a Certificate.

I was trying to highlight that Certificates are statements of fact, and there shouldn't be any property rights associated to begin with, but it would be better for NBP to make clear that it's not asserting property rights over that.

Equally, if I include an OCSP response stapled within a TLS packet, is that a transformative derivative, even if the full OCSP response is maintained? If I display a textual version on crt.sh, is that a derivative? This again goes back to the "Things signed by the CA are statements of fact by the CA" and not granted property rights to begin with.

Comment 39

[Han Yong, Park]

(In reply to Ben from comment #37)
Hello Ben, I reply to your comment as below.

Could you look into a couple of CRL provisioning errors?

When I run this test - https://certificate.revocationcheck.com/test-certificate.naver.com I get the following warnings for the CRLs
http://ica.navercorp.com/crl/Crl1p1Dp1.crl and http://rca.navercorp.com/arl/Arl1Dp1.crl:

WARNING: Last-Modified header is not the same as ThisUpdate (RFC 5019, section 6.2)

NBP also had recognized the time differences, but in the case of CRLs, It seems that other CAs also have time differences. Should CRL's ThisUpdate and Last-Modified header be the same, and NextUpdate and Expires header be the same? If there are any CABF requirements, please let us know. Our OCSP response information meets RFC 5019.

WARNING: Expires cache header not set (RFC 5019, section 6.2)

NBP fixed this warning today. It has been set expires cache header to 3 days. Same as the above question, Expires header is not the same as NextUpdate.

Comment 40

[Han Yong, Park]

Hello Ryan,
Following your Comment #38, NBP decided to replace the OCSP responder certificate with a certificate with a validity period of 90 days. Due to the certificate replacement, we reply our opinion on Comment #38 and draft contents of newly revised CPS v1.4.3 first.
Please let me know if you have any further questions or feedback.

• 3.2.2.1: Describes what they "could" do, but it's unclear if that's actually what they actually do.

No substantive changes made to this section.

Combined with the answer from Comment #32 (the use of DUNS), I'm concerned about this, because we've seen quality control issues re: DUNS and addresses. However, this is a broader issue with CAs, and more in line with the set of problems that CA/B Forum Ballot SC30 is trying to address (although that is presently just limited to EV).

I would encourage NAVER to add specific details here about the steps taken to validate identity and sources used (including listing DUNS)

Please check CPS v1.4.2 Section 3.2.2.1 where detailed steps that verify identity and address have been added. As specified in CPS v1.4.2, NBP receives a Business License and/or Government issued tax document. The unique business license number identified after submission is double-checked with the trusted third party's database. In South Korea, the Business License is issued by the government, so you can check and verify the database provided by the government. Databases of the National Tax Service, Supreme Court, and Financial Supervision Service are typically used.

• 3.2.2.4: Doesn't describe whether or not they reuse domain validation data, and if so, for how long, nor does it document that they maintain records of the validation method (and, ideally, how that information is maintained). I placed this as Bad, rather than Meh, because this is the only time we have for the CA to really document how they manage this in a binding way.
  • Notably, 4.2.1 just points back to 3.2, so it's unclear in either place where a discussion of data reuse might be discussed if/how that's handled.

NAVER states in Comment #32 "NBP doesn’t reuse domain validation data".

However, section 3.2.2.7 sets forth an 825-day period for which re-validation is required. This should be changed because (and NAVER should be on alert that) the certificate lifetime for SSL/TLS server certificates will soon be a 397-day maximum validity period. Section 6.3.2 of the CPS will also need to be amended.

Sure, but as it stands today, the conspicuous lack of saying something (e.g. what was said in Comment #32) is a bit troubling. I think it's useful here to capture (in 3.2.2.7) that domains are validated no more than X days prior to issuance of a certificate. I assume there's some delta X between validation and the actual issuance of the certificate, whether it be one second or one year, so specifying that is useful.

As written, 3.2.2.7 could be read that "Authority of Applicant" is the domain validation, which I don't think is the intent?

The solution here is to be explicit within the CP/CPS how DNS reuse and revalidation is handled

For NBP, every single certificate application has a 30-day subscription period. If domain validation is successful, the validation information is valid before the certificate is issued or until 30 days have elapsed. Therefore, the X day mentioned in the comment is within 30 days. We have added 'Domain Name' in Section 3.2.2.7 of the revised CPS v1.4.3. The 'Authority of Applicant' is deleted since it was an ambiguous information.

Revision of CPS: Domain Name - No longer than 30 days, running every single certificate application process (newly added in section 3.2.2.7)

• 4.9.9: Uses delegated responder certificates, which make for chunkier OCSP responses. A profile for the responder certificate is not provided in Appendix A, which is why this is "Bad" and not "meh" for just the fat responses.

Section now states, "OCSP Responder Certificate profile is included in Appendix A."

The profile omits the mandatory id-pkix-ocsp-nocheck extension that has been the subject of much discussion on m.d.s.p. and on many CA incidents. This should be included in the Profile.

However, also concerning is that the validity period for OCSP responder certificates is quite large (in this case, approximately 2 years). This is somewhat inconsistent with https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1 and thus still under the BAD list. Because nocheck is required, OCSP responders should be kept short-lived (e.g. 30 - 90 days) to reduce risk, because it's effectively as bad as a CA compromise.

Missing id-pkix-ocsp-nocheck has been added to the revised CPS v1.4.3. The validity period of the OCSP responder certificate will be changed to 90 days. The certificate will be replaced within this month.

Revision of CPS: validity periods will be change to 90 days in Appendix A OCSP Responder Certificate.

• 9.5: Prohibits distribution of NAVER certificates as trust anchors (e.g. partial representation). The problematic language is asserting the Certificates as the exclusive property and can only be reproduced or distributed "in full", and prohibiting "derivative works". At fundamental question is whether or not a Certificate is a copyrightable concept, since it's a statement of a fact (like a phone number for a business), as opposed to a creative or transformative endeavor; it may be worth revisiting this section again entirely with your lawyers to think about this approach.

Section 9.5.1 has been amended and the following language has been deleted: "The NAVER BUSINESS PLATFORM grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full."

I'm not seeing that in 9.5.1 of v1.4.2 attached in Comment #36.

But to clarify this more: It would be better to make it clear that NBP is not asserting property rights on the certificates it produces, period. If I'm developing, say, an embedded application, I may only have memory to store a DN and a public key (e.g. BearSSL and other embedded SSL libraries often implement root stores via this). In one perspective, that's a derivative work of a Certificate.

I was trying to highlight that Certificates are statements of fact, and there shouldn't be any property rights associated to begin with, but it would be better for NBP to make clear that it's not asserting property rights over that.

Equally, if I include an OCSP response stapled within a TLS packet, is that a transformative derivative, even if the full OCSP response is maintained? If I display a textual version on crt.sh, is that a derivative? This again goes back to the "Things signed by the CA are statements of fact by the CA" and not granted property rights to begin with.

NBP has carefully reviewed this section and we agree that "things signed by the CA are not granted property rights but are statements of fact by the CA". This is clearly stated in the revised CPS Section 9.5.1. Thank you for your consistent opinion on this topic.

Revision of CPS: We are planning to add “NAVER BUSINESS PLATFORM does not knowingly violate the intellectual property rights of third parties” at the beginning of the CPS section 9.5.

Also, the section 9.5.1 will be amended as below: 

(Delete)
The Intellectual Property Rights pertaining to the Certificates of CAs and revocation information that are issued by CAs shall be retained by those CAs.
NAVER BUSINESS PLATFORM does not allow derivative works of its Certificates or products without prior written permission.

(Insert)
NAVER BUSINESS PLATFORM grants permision to reproduce and distribute certificates on a non-exclusive, royalty free basis, since certificate and revocation information produced by NAVER BUSINESS PLATFORM's CA are statements of fact.
NAVER BUSINESS PLATFORM reserves the right to revoke a certificate at any time and at its sole discretion, and has a liability to maintain revocation information.

Comment 41

[Han Yong, Park]

Attachment: NAVER BUSINESS PLATFORM CPS v1.4.3 ENGLISH

NBP attached the new CPS v1.4.3 updated in 7 October, 2020.

Comment 42

[Ben Wilson]

Thank you. These changes look very good. I will review and prepare your inclusion application for the public discussion phase.

Comment 43

[Ben Wilson]

Public discussion has begun - https://groups.google.com/g/mozilla.dev.security.policy/c/edkFKcdJWZU/m/iByjlwA_AwAJ
Public discussion is scheduled to close on Monday, 2-November-2020
According to the root inclusion process, https://wiki.mozilla.org/CA/Application_Process:
"A representative of the CA responds to questions and concerns posted during the public discussion of the CA's request."
This should be done on the m.d.s.p. list.

Comment 44

[Ben Wilson]

Hi Kathleen,
The three-week public discussion period for this request to include NAVER in the root store concluded yesterday with notice of Mozilla's intent to approve on mdsp, https://groups.google.com/g/mozilla.dev.security.policy/c/edkFKcdJWZU/m/StSuVsmjAgAJ. According to Step 10 in the process description, https://wiki.mozilla.org/CA/Application_Process#Process_Overview, "After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug." NAVER is just seeking enablement of the websites trust bit. Thanks. Ben

Comment 45

[Kathleen Wilson]

As per Comment #44, and on behalf of Mozilla I approve this request from NAVER Cloud to include the following root certificate:

** 'NAVER Global Root Certification Authority' (Websites)

I will file the NSS bug for the approved changes.

Comment 46

[Kathleen Wilson]

I have filed bug #1678166 against NSS for the actual changes.