Step 6 of CA Application Process <https://wiki.mozilla.org/CA/Application_Process>: *Summary of Discussion and Resulting Decision:*
One commenter stated that it appeared that a few certificates were misissued, i.e. that the stateOrProvinceName field (“S” field) should probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city. A NAVER representative responded that it had fixed the DN structure with L equal to "Seongnam-si" as city name and S field as "Gyeonggi-do" for province name. NAVER also added a procedure, in compliance with ISO 3166-2, to put province information correctly in the S field of user DN for newly issued certificates. A second commenter noted that: (1) wording in the CPS could allow NAVER to avoid revoking problematic certificates by relying on Korean law; (2) “relevant legislation” was not referenced in sections 9.14 and 9.16.3 as required by BR section 9.16.3; and (3) the list of events logged did not include "All verification activities" as required by BR section 5.4.1(2). Responses to the foregoing included the following: (1) a certificate not revoked because of Korean law would be a BR violation and the CA would be required to previously disclose this according to BR section 9.16.3 (the conflicting requirement could be modified “to the minimum extent necessary to make the requirement valid and legal” and the CA would have to notify the CA/Browser Forum of such practice change so that the Forum could react appropriately. NAVER also stated, “we found that there are no South Korea’s laws and regulations which affect or refuse the revocation of certificates that violated the BRs issued by a commercial CA”. (2) A third commenter stated, “Note that, in this case, the particular language you're concerned about is part of the BRs themselves, in 4.9.5. However, this is about ‘when’ to revoke. I think you raise an interesting point that would benefit from clarification from NAVER, because I think you're correct that we should be concerned that the shift from ‘when’ to revoke has become ‘whether’ to revoke, and that is an important difference.” As a result of these comments, NAVER amended sections 4.9.5, 9.14, and 9.16.3. Section 4.9.5 of the NAVER CPS now reads, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation must not exceed the time frame set forth in Section 4.9.1.1. The date selected by NAVER Cloud will consider the following criteria: … Relevant legislation.” Section 9.14 of the NAVER CPS now states, “This CPS is governed, construed and interpreted in accordance with the laws of Republic of Korea. This choice of law is made to ensure uniform interpretation of this CPS, regardless of the place of residence or place of use of NAVER Cloud Certificates or other products and services. The law of Republic of Korea applies also to all NAVER Cloud commercial or contractual relationships in which this CPS may apply or quoted implicitly or explicitly in relation to NAVER Cloud products and services where NAVER Cloud acts as a provider, supplier, beneficiary receiver or otherwise.” (Note that section 1.1 of the NAVER CPS states, “In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this document.”) Section 9.16.3 has been amended by adding a paragraph reading, “In the event of a conflict between CABF Baseline Requirements and a law, regulation or government order (hereinafter ‘Law’) of any jurisdiction in which a CA operates or issues certificates, NAVER Cloud modifies any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, NAVER Cloud immediately (and prior to issuing a certificate under the modified requirement) includes in Section 9.16.3 of this CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by NAVER Cloud.” (3) Section 5.4.1 now states that “NAVER Cloud records at least the following events: … 2. Subscriber Certificate lifecycle management events, including: … b. All verification activities stipulated in these Requirements and the CA’s Certification Practice Statement”. A key take-away from a review of these comments and responses is the need for each CA’s CPS language to provide a firm commitment to revoke certificates on a timely basis. I think members of the Mozilla community do not want to have to worry about “when” or “whether” a certificate will be revoked. In sections 4.9.1.1 and 4.9.5 of the NAVER CPS, NAVER has adopted essentially the 24-hour and 5-day timeframes of sections 4.9.1.1 and 4.9.5 of the Baseline Requirements. Certainly, all CAs could improve the descriptions of their revocation processes, but this language in the NAVER CPS meets the minimum requirements. Hopefully, NAVER and other CAs will not only strive to improve their CPS revocation language, but also strive to revoke certificates quickly when one of the criteria is met. Are there any final comments or issues that have not been addressed? If not, I will be closing public discussion tomorrow [Step 9] and giving notice that it is Mozilla’s intent to approve NAVER's request for inclusion [Step 10]. Thanks, Ben On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thank you all for the comments during the public discussion phase. > All matters raised in this public discussion has been fixed and then > published > our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14, > and 9.16.3. > > You can find the revised CPS v1.5.0 at our repository. > https://certificate.naver.com/bbs/initCrtfcJob.do > (directly download link: > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf > ) > > To minimize confusion, I would like to metion that "NAVER BUSINESS > PLATFORM" > has been renamed to "NAVER Cloud" without any changes on the ownership of > the company and Certification Authority on October 26, 2020. > > Kind Regards, > Sooyoung Eo > > > 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용: > > 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=00000261 > > > > > > > > > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 > to > > > > > 8/18/2037 > > > > > > > > > > SHA2: > 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265 > > > > > > > > > > https://crt.sh/?id=1321953839 > > > > > > > > > > Root Certificate Download: > > > > > > > > > > > > > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt > > > > > > > > > > CP/CPS: > > > > > > > > > > Comments 29 ( > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29) > > > > > > > > through 42 in Bugzilla contain discussion concerning the CPS and > > > revisions > > > > > thereto. > > > > > > > > > > Current CPS is version 1.4.3: > > > > > > > > > > > > > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP > > > Certification Practice Statement v1.4.3.pdf > > > > > > > > > > Repository location: > https://certificate.naver.com/bbs/initCrtfcJob.do > > > > > > > > > > BR Self Assessment (Excel file) is located here: > > > > > > > > > > https://bugzilla.mozilla.org/attachment.cgi?id=9063955 > > > > > > > > > > Audits: Annual audits are performed by Deloitte according to the > > > > > WebTrust Standard and WebTrust Baseline Requirements audit > criteria. > > > See > > > > > webtrust.org. The last complete audit period for NAVER was from 1 > > > December > > > > > 2018 to 30 November 2019 and no issues were found. However, the > audit > > > > > report was dated 28 April 2020, which was more than three months > > > following > > > > > the end of the audit period. The explanation for the delay in > > > obtaining the > > > > > audit report was as follows, “NBP had received a notification mail > on > > > > > updating the audit information from CCADB support in March since > the > > > Root > > > > > certificate is only included into Microsoft Root Program. > According to > > > > > instructions on the email, I explained that NBP would submit the > audit > > > > > update information in April to Microsoft.” The current audit > period > > > ends > > > > > 30 November 2020. > > > > > > > > > > *Mis-Issuances * > > > > > > > > > > According to crt.sh and censys.io, the issuing CA under this root > > > > > (NAVER Secure Certification Authority 1) has issued approximately > 80 > > > > > certificates. I ran the following query for the issuing CA to > identify > > > any > > > > > mis-issuances: > > > > > > > > > https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-08-18, > > > > > > > > > and during the course of our review, we identified six test > > > certificates > > > > > with errors. (Such certificates have either been revoked or have > > > expired). > > > > > See: > > > > > > > > > > https://crt.sh/?id=2132664529&opt=cablint,zlint,x509lint > > > > > > > > > > https://crt.sh/?id=2102184572&opt=cablint,zlint,x509lint > > > > > > > > > > https://crt.sh/?id=1478365347&opt=cablint,zlint,x509lint > > > > > > > > > > https://crt.sh/?id=2149282089&opt=cablint,zlint,x509lint > > > > > > > > > > https://crt.sh/?id=2149282369&opt=cablint,zlint,x509lint > > > > > > > > > > https://crt.sh/?id=2282123486&opt=cablint,zlint,x509lint > > > > > > > > > > The explanation provided ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was > > > “Regarding > > > > > CA/B Forum and X.509 lint tests NBP figured out two(2) > certificates > > > which > > > > > were not complied with BRs right after issuing them. The domains > on > > > SANs of > > > > > the certificates were owned and controlled by NBP. They were > > > immediately > > > > > revoked according to CA procedures. For ZLint tests, the > certificate > > > (CN= > > > > > test2-certificate.naver.com) had been issued and became expired > in > > > > > compliance with CA Browser Forum BRs and RFC 5280. I understand > there > > > is a > > > > > specific Mozilla policy on Authority Key IDs. NBP already fixed > the > > > system > > > > > functions. There is no such valid certificate and NBP CA currently > > > issues > > > > > certificates fully complied with the Mozilla policy. You can see > the > > > new > > > > > certificate (CN= test2-certificate.naver.com) was issued without > any > > > error > > > > > at https://crt.sh/?id=2824319278.” > > > > > > > > > > I have no further questions or concerns at this time, however I > urge > > > anyone > > > > > with concerns or questions to raise them by replying to this list > > > under the > > > > > subject heading above. > > > > > > > > > > Again, this email begins a three-week public discussion period, > which > > > I’m > > > > > scheduling to close on Monday, 2-November-2020. > > > > > > > > > > Sincerely yours, > > > > > > > > > > Ben Wilson > > > > > > > > > > Mozilla Root Program > > > > > > > > > > dev-security-policy mailing list > > > > > dev-secur...@lists.mozilla.org > > > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > > 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. > > > _______________________________________________ > > > dev-security-policy mailing list > > > dev-secur...@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
