On August 3, 2021, we began a three-week public discussion[1] on a request by Chunghwa Telecom (Chunghwa) to include its certificate for the HiPKI Root CA - G1 .[2] (Step 4 of the Mozilla Root Store CA Application Process [3]).
*Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:* One commenter asked about levels 1 through 4 and whether there was a minimum security level that CAs needed to meet. Chunghwa responded that the levels were not security levels but identity assurance levels, and to clarify other matters raised in this and other comments, Chunghwa updated its CP and CPS[4]. Another comment asked about domain validation methods, automation, and whether a risk assessment had been performed for each validation method. Chunghwa responded that it had performed a risk assessment and had followed relevant discussions of the Validation Subcommittee of the Server Certificate Working Group of CA/B Forum, which had adopted the allowed methods of domain validation. Chunghwa also clarified in its response and in its CPS about when it performs automated processing of certificate requests. Andrew Ayer noted that the CPS permitted Chunghwa to ignore CAA lookup errors if the error was outside its infrastructure and there was no DNSSEC validation chain to the ICANN root. There was concern about errors if this process were manual. Questions asked were: which tools and DNS resolver(s) were used to perform DNS lookup; how does the manual process determine whether the domain has a DNSSEC validation chain to the ICANN root; and how does the RA Officer determine if a DNS failure has occurred outside the CA’s infrastructure? Andrew also noted that when standard DNS resolvers (e.g. dig) encounter an error, they don't report any information about DNSSEC and don’t distinguish between an error due to an invalid DNSSEC signature (don’t issue) and an externally-caused error in an unsigned zone (may issue after a retry). Chunghwa responded that its system performs the CAA record lookup with an automated Dig command (version 9.11.4 with reference to DNS RCODE). The query request is sent to Chunghwa’s DNS resolver which supports the checking of DNSSEC validation chain to the ICANN root. It said its CAA checking is in accordance with BR 3.2.2.8, and a certificate is permitted to issue if: a. the dig output is ‘NOERROR’ or some other status; and b. the lookup has been retried at least once; and c. there does not have a DNSSEC validation chain to the ICANN root. Chunghwa provided an additional overview of its CAA-processing steps in response to the follow-up question from Andrew. Another comment was that Chunghwa only issued EV certificates, for which issuance cannot be automated, and therefore harder to revoke and replace when misissued, adding risk to Firefox users. Chunghwa responded that it had implemented automatic domain validation functionality in its RA system to mitigate human error, and that it did not see a problem with revoking and replacing misissued certificates within BR-mandated timelines. Another comment was that section 3.2.5.4 of the CPS does not reference the corresponding BR section. Section 3.2.5.4 of the Chunghwa CPS now references Section 3.2.2.4.18 of the Baseline Requirements. There was a query about the pre-issuance linting software used by Chunghwa. Chunghwa responded that it uses a self-developed module based on ZLint. *Action Items* I don’t believe there are any pending action items to complete. However, I note that its 2021 audit is now due. *Close of Public Discussion and Intent to Approve **[Application Process, Steps 9-10]:* This is notice that I am closing public discussion (Application Process, Step 9) and that it is Mozilla’s intent to approve Chunghwa Telecom’s request (Step 10). This begins a 7-day “last call” period for any final objections. Thanks, Ben [1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/uvdF8RTRFPc/m/P94Q6Q5YAQAJ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1563417 [3] https://wiki.mozilla.org/CA/Application_Process#Process_Overview [4] https://eca.hinet.net/repository-h/en/index.htm On Wed, Sep 15, 2021 at 11:00 AM Ben Wilson <[email protected]> wrote: > I have reviewed the changes to Chunghwa Telecom's CP and CPS. Minor > amendments were made to CP Sections 6.6.2 and 8. Other changes were made to > the CPS to change some terminology, to clarify actual validation and > CAA-checking practices, and to update the CPS to comply with CABF Ballot > SC48. See CPS Sections 1.3.2, 1.6.1, 3.1.3, 3.2.2.7, 3.2.4, 3.2.5, 3.2.5.2, > 3.2.5.3, 3.2.5.4, 3.2.5.6, 3.2.5.7, 4.2.1, 4.2.2 and 7.1.4.2.1. > > I will begin preparing a summary of the discussion and notice that the > public discussion phase of the application process is closed. > > Ben > > On Wed, Sep 15, 2021 at 7:50 AM Li-Chun CHEN <[email protected]> > wrote: > >> Dear All, >> >> We have released the latest version of CP & CPS (HiPKI CP v1.16 and >> HiPKI EV TLS CA CPS v1.1.7) on our official website >> https://eca.hinet.net/repository-h/en/index.htm , please kindly review >> them, thanks. >> >> The updated HiPKI CP: >> https://eca.hinet.net/download/HiPKI-CP-v1.16-en.pdf >> The updated HiPKI EV TLS CA CPS >> https://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.17-en.pdf >> >> Regards, >> >> Li-Chun Chen >> Chunghwa Telecom Co., Ltd. >> >> [email protected] 在 2021年8月25日 星期三上午3:49:11 [UTC+8] 的信中寫道： >> >>> All, >>> I will leave the public discussion phase open in order for Chunghwa >>> Telecom to provide an updated CPS. >>> Ben >>> >>> On Tue, Aug 24, 2021 at 10:16 AM Li-Chun CHEN <[email protected]> >>> wrote: >>> >>>> Hi, Andrew, >>>> >>>> We have implemented the automatic domain validation functionality >>>> to our RA system to prevent a high risk of human error since last year, so >>>> that’s not the problem to revoke and replace misissued certificates within >>>> the BR-mandated timelines. After reviewing our CPS again, we found that >>>> many places did not reflect our validation processes in practice within >>>> this English version of CPS that make you think all these operations are >>>> performed manually by RAOs. Obviously, we need to revise our English >>>> version of CPS (in Sections 3.1.3, 4.2.1, etc.) again and shall be done >>>> more carefully. >>>> >>>> Responses to other questions that you raised are as follows: >>>> >>>> =================================================================== >>>> >>>> 3. Section 3.2.5.4 of the CPS does not reference the corresponding BR >>>> section. This is a violation of Mozilla Root Store Policy. >>>> >>>> => That is the omission in translation, we will deal with it in the >>>> revised version. >>>> >>>> 1. What pre-issuance linting software is used? >>>> >>>> => We check tbsCertificate according to RFC 5280, SSL BR, EV >>>> Guildlines, Mozilla Policy, and our CP/CPS, as well as make an additional >>>> check (including matches with blacklist and phishing list) by using a >>>> self-developed Linter module, which use the open source of ZLint as a base >>>> and will update depends on its regularly releases, prior to the issuance of >>>> SSL cert. >>>> >>>> >>>> >>>> 2. Please describe in detail the process for CAA checking. What tools >>>> are used to perform the lookup? What DNS resolver is queried and who >>>> operates it? How does the RAO determine whether the domain has a DNSSEC >>>> validation chain to the ICANN root? How does the RAO determine if a DNS >>>> failure has occurred outside "HiPKI EV TLS CA's infrastructure"? >>>> >>>> => Our RA system performs the CAA record lookup by using the Dig >>>> command, which is not performed by our RAOs manually, and the query request >>>> is send to our HiNET DNS resolver (Chunghwa Telecom is a domain name >>>> registrar as well) which supports the checking of DNSSEC validation chain >>>> to the ICANN root. If the status response of Dig request is not ‘NOERROR’, >>>> our system will treat it as a record lookup failure and can therefore issue >>>> the certificate. >>>> >>>> Sincerely yours, >>>> >>>> Li-Chun >>>> >>>> Andrew Ayer 在 2021年8月23日 星期一上午1:21:11 [UTC+8] 的信中寫道： >>>> >>>>> I have the following concerns about Chunghwa Telecom: >>>>> >>>>> 1. Both domain validation (CPS section 3.1.3) and CAA checking (CPS >>>>> section 4.2.1.1) are performed manually by RA officers. Their CPS >>>>> permits them to ignore CAA lookup errors if the error is outside their >>>>> infrastructure and there is no DNSSEC validation chain to the ICANN >>>>> root. Doing this properly requires specialized knowledge of what DNS >>>>> queries to make and how to interpret the responses. The training >>>>> requirements for RAOs (CPS section 5.3.3) do not include training that >>>>> is relevant to this, but even if they did, there would still be a high >>>>> risk of human error due to the nuances involved. >>>>> >>>>> 2. They issue only EV certificates, whose issuance cannot be >>>>> automated. >>>>> This runs contrary to Mozilla's goal to encourage certificate >>>>> automation. >>>>> Without automation, it's harder to revoke and replace misissued >>>>> certificates within the BR-mandated timelines, which increases risk >>>>> to Firefox users. And since Firefox no longer gives EV certificates >>>>> special treatment in the URL bar, EV certificates don't provide any >>>>> value to Firefox users. >>>>> >>>>> 3. Section 3.2.5.4 of the CPS does not reference the corresponding >>>>> BR section. This is a violation of Mozilla Root Store Policy. >>>>> >>>>> I have the following questions for Chunghwa Telecom, but regardless I >>>>> don't think this application should be approved unless the above >>>>> problems are fixed. Mozilla should not be adding new CAs in the year >>>>> 2021 that perform manual DV/CAA and only support inherently manual >>>>> certificate issuance. >>>>> >>>>> 1. What pre-issuance linting software is used? >>>>> >>>>> 2. Please describe in detail the process for CAA checking. What tools >>>>> are used to perform the lookup? What DNS resolver is queried and who >>>>> operates it? How does the RAO determine whether the domain has a >>>>> DNSSEC >>>>> validation chain to the ICANN root? How does the RAO determine if a >>>>> DNS failure has occurred outside "HiPKI EV TLS CA's infrastructure"? >>>>> >>>>> Regards, >>>>> Andrew >>>>> >>>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c05706a8-8be3-4cd5-a0a6-de50aae54f11n%40mozilla.org >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c05706a8-8be3-4cd5-a0a6-de50aae54f11n%40mozilla.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaqe-WM6Z80SPehmFk4Q05ZCLRNpbbJa39R4ihiXLXW0Q%40mail.gmail.com.
