" And since Firefox no longer gives EV certificates special treatment in the URL bar, EV certificates don't provide any value to Firefox users."
FYI: Most browsers, including Firefox display EV certificates uniquely. By clicking on the lock, it's immediately evident that a site is using EV and hence, the benefit is there. Only EV certificates will show "Connection Secure. Certificate issued to <name of company>". No other cert type gets this treatment. Dean -----Original Message----- From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Andrew Ayer Sent: Sunday, August 22, 2021 1:21 PM To: dev-security-policy@mozilla.org Subject: Re: Public Discussion of Chunghwa Telecom's Root Inclusion Request 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210822132108.1e62dcd9077578ab816d9b03%40andrewayer.name. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/004701d79794%247194f360%2454beda20%24%40verizon.net.
