Re: NAVER: Public Discussion of Root Inclusion Request
On Wed, Oct 21, 2020 at 2:09 PM Matthias van de Meent via dev-security-policy wrote: > Hi, > > In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following: > > > 4.9.3 Procedure for Revocation Request > > The NAVER BUSINESS PLATFORM processes a revocation request as follows: > > [...] > > 4. For requests from third parties, The NAVER BUSINESS PLATFORM > personnel begin investigating the request within 24 hours after receipt and > decide whether revocation is appropriate based on the following criteria: > > a. [...], b. [...], c. [...], d. [...] > > e. Relevant legislation. > > The wording here is concerning, as it points to potential legislation > that could disallow NAVER from revoking problematic certificates. Also > of note is that this 'relevant legislation' is not referenced in > section 9.14, Governing Law, nor in 9.16.3, Severability (as required > per BRs 9.16.3). > If I understand your concern, you're concerned about a decision to /not/ revoke a given certificate, correct? You're indeed accurate that a certificate that violated the BRs, but was not revoked according to relevant legislation, would be a BR violation and the CA would have been required to previously disclose this according to 9.16.3. However, CAs are also free to *add* reasons for revocation, and to consider part of their investigation. relevant legislation which might lead to revocation even if it wasn't a violation of NAVER's CP/CPS. This is totally fine, and all CAs are entitled to add additional requirements, and for relying parties/root programs to consider those reasons relevant to their user communities. Note that, in this case, the particular language you're concerned about is part of the BRs themselves, in 4.9.5. However, this is about "when" to revoke. I think you raise an interesting point that would benefit from clarification from NAVER, because I think you're correct that we should be concerned that the shift from "when" to revoke has become "whether" to revoke, and that is an important difference. > I also noticed that the "All verification activities" type of event is > not recorded, or at least not documented as such. This is a > requirement from BRs 5.4.1(2)(2). > Thanks for the excellent attention to detail! I agree, this would be concerning, especially given the importance this log has been in investigating CA misissuance in the past. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: NAVER: Public Discussion of Root Inclusion Request
Hi, In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following: > 4.9.3 Procedure for Revocation Request > The NAVER BUSINESS PLATFORM processes a revocation request as follows: > [...] > 4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel > begin investigating the request within 24 hours after receipt and decide > whether revocation is appropriate based on the following criteria: > a. [...], b. [...], c. [...], d. [...] > e. Relevant legislation. The wording here is concerning, as it points to potential legislation that could disallow NAVER from revoking problematic certificates. Also of note is that this 'relevant legislation' is not referenced in section 9.14, Governing Law, nor in 9.16.3, Severability (as required per BRs 9.16.3). I also noticed that the "All verification activities" type of event is not recorded, or at least not documented as such. This is a requirement from BRs 5.4.1(2)(2). Regards, Matthias On Sat, 10 Oct 2020 at 00:09, Ben Wilson via dev-security-policy wrote: > > Dear All, > > This is to announce the beginning of the public discussion phase of the > Mozilla root CA inclusion process, > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 > through 9). Mozilla is considering approval of NAVER Business Platform > Corp.’s request to include the NAVER Global Root Certification Authority as > a trust anchor with the websites trust bit enabled, as documented in the > following Bugzilla case: > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a > 3-week comment period, after which if no concerns are raised, we will close > the discussion and the request may proceed to the approval phase (Step 10). > > *A Summary of Information Gathered and Verified appears here in the CCADB:* > > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261 > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to > 8/18/2037 > > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265 > > https://crt.sh/?id=1321953839 > > *Root Certificate Download:* > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_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_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf > > Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do > > *BR Self Assessment* (Excel file) is located here: > > https://bugzilla.mozilla.org/attachment.cgi?id=9063955 > > *Audits:* Annual audits are performed by Deloitte according to the > WebTrust Standard and WebTrust Baseline Requirements audit criteria. See > webtrust.org. The last complete audit period for NAVER was from 1 December > 2018 to 30 November 2019 and no issues were found. However, the audit > report was dated 28 April 2020, which was more than three months following > the end of the audit period. The explanation for the delay in obtaining the > audit report was as follows, “NBP had received a notification mail on > updating the audit information from CCADB support in March since the Root > certificate is only included into Microsoft Root Program. According to > instructions on the email, I explained that NBP would submit the audit > update information in April to Microsoft.” The current audit period ends > 30 November 2020. > > *Mis-Issuances * > > According to crt.sh and censys.io, the issuing CA under this root > (NAVER Secure Certification Authority 1) has issued approximately 80 > certificates. I ran the following query for the issuing CA to identify any > mis-issuances: > https://crt.sh/?caid=126361=cablint,zlint,x509lint=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=cablint,zlint,x509lint > > https://crt.sh/?id=2102184572=cablint,zlint,x509lint > > https://crt.sh/?id=1478365347=cablint,zlint,x509lint > > https://crt.sh/?id=2149282089=cablint,zlint,x509lint > > https://crt.sh/?id=2149282369=cablint,zlint,x509lint > > https://crt.sh/?id=2282123486=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
CCADB Proposal: Add field called Full CRL Issued By This CA
All, Root store operators would like to easily find and use the URLs to the Full CRLs for things like Mozilla’s CRLite. The BRs do not require CRL URLs in end-entity certificates, and many CAs use partitioned CRLs for end-entity certificates. Proposal: Add field called 'Full CRL Issued By This CA' - New field on intermediate certificate records which may be filled in by CAs or root store operators when the certificate signs certificates that do not contain CRL URLs or only contain URLs to partitioned CRLs. - This field would be included in public-facing reports such as http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat so that it can be used programmatically by root store operators, and could also be provided in crt.sh. - Also add this field to root certificate records, even though only root store operators can currently update root certificate records. I will appreciate your input on this proposal. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: NAVER: Public Discussion of Root Inclusion Request
Here is NAVER's response which I am forwarding from them: Here is NAVER Business Platform's response to the comment: - Hello, I am Sooyoung at NAVER Business Platform. As George mentioned, all the certificates, with both of city and province names in stateOrProvinceName field, were issued to NAVER Business Platform (NBP) for test domains. The addresses were verified correctly when issuing them. NBP reflected George’s comment and has fixed the DN structure. You can directly check the issued certificate including the new DN (L is "Seongnam-si" as city name and S field is "Gyeonggi-do" as province name) as below. https://crt.sh/?id=3510606493 NBP also added additional verification process, in compliance with ISO 3166-2, in order to put province information correctly in S field of user DN for newly issued certificates. - Best Regards, Sooyoung Eo On Fri, Oct 9, 2020 at 4:30 PM George wrote: > Minor but it seems like all certificates with a stateOrProvinceName field > are misissued. The ST field should probably be the "Gyeonggi-do" as the > "Seongnam-si" entered is a city. > > > > ‐‐‐ Original Message ‐‐‐ > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Dear All, > > > > This is to announce the beginning of the public discussion phase of the > > Mozilla root CA inclusion process, > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, > (Steps 4 > > through 9). Mozilla is considering approval of NAVER Business Platform > > Corp.’s request to include the NAVER Global Root Certification Authority > as > > a trust anchor with the websites trust bit enabled, as documented in the > > following Bugzilla case: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate > a > > 3-week comment period, after which if no concerns are raised, we will > close > > the discussion and the request may proceed to the approval phase (Step > 10). > > > > A Summary of Information Gathered and Verified appears here in the CCADB: > > > > > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261 > > > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to > > 8/18/2037 > > > > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265 > > > > https://crt.sh/?id=1321953839 > > > > Root Certificate Download: > > > > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_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_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_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=cablint,zlint,x509lint=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=cablint,zlint,x509lint > > > > https://crt.sh/?id=2102184572=cablint,zlint,x509lint > > > > https://crt.sh/?id=1478365347=cablint,zlint,x509lint > > > > https://crt.sh/?id=2149282089=cablint,zlint,x509lint > > > > https://crt.sh/?id=2149282369=cablint,zlint,x509lint > > > > https://crt.sh/?id=2282123486=cablint,zlint,x509lint > > > > The explanation provided ( > >
