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/b0bb9c93-7376-42ef-b715-50101cf7a7b4n%40mozilla.org.
