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%2B1gtab9JhX%3DdTJsy1%3D1_o-YpjsGH5GWy7yox5foJkLv24U1tA%40mail.gmail.com.
