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.

Reply via email to