Public Discussion of Chunghwa Telecom's Root Inclusion Request

[Ben Wilson]

Chunghwa Telecom

This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for Chunghwa Telecom’s request to include the HiPKI Root CA - G1 Certificate in the root store as an TLS/SSL-only root CA. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).

Mozilla is considering approving Chunghwa Telecom’s request to add the root as a trust anchor with the websites trust bit and EV enabled as documented in Bugzilla bug #1563417. This email begins the 3-week comment period, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10).

A Summary of Information Gathered and Verified appears here in the CCADB:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000491

HiPKI Root CA - G1 is valid from 2/22/2019 to 12/31/2037

SHA2 Certificate Hash: F015CE3CC239BFEF064BE9F1D2C417E1A0264A0A94BE1F0C8D121864EB6949CC

https://crt.sh/?id=1639768443

Root Certificate Download:

http://eca.hinet.net/download/HRCA.cer (DER)

http://eca.hinet.net/download/HRCA_b64.crt (PEM)

CP/CPS:  Effective June 17, 2021, the current CP and CPSes for the Chunghwa’s HiPKI Root CA - G1 Certificate are:  http://eca.hinet.net/download/HiPKI-CP-v1.15-en.pdf; http://eca.hinet.net/download/HiPKI-RCA-CPS-v1.16-en.pdf; and http://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.16-en.pdf.

Repository location: https://eca.hinet.net/repository-h/en/index.htm

Test Websites:

https://good.hipkig1ev.hinet.net

https://revoked.hipkig1ev.hinet.net

https://expired.hipkig1ev.hinet.net

 

BR Self Assessment (Excel) is located here:    https://bugzilla.mozilla.org/attachment.cgi?id=9075869

Audits:  Annual audits are performed by Sunrise CPAs / DFK International. The most recent audits received by Mozilla were for the period ending May 31, 2020, and performed according to WebTrust audit criteria -- Standard, Baseline Requirements and EV Guidelines. WebTrust seals were issued.  See here: https://tls.hinet.net/.  We expect to be receiving the 2021 WebTrust audit reports soon.

Incident Reports / Mis-Issuances

The following bugs/incidents involving Chunghwa Telecom have been reported and closed.

Bug 1532436 - Test certificate with unregistered domain name

No misissuances were found under this root, and certificates issued under it have passed testing.  

I have no further questions or concerns at this time, however I urge anyone with concerns or questions to raise them on this list by replying under the subject heading above.

A representative of Chunghwa Telecom must promptly respond directly in the discussion thread to all questions that are posted.

Again, this email begins a three-week public discussion period, which I’m scheduling to close on August 24, 2021.

Sincerely yours,

Ben Wilson

Mozilla Root Program

[Watson Ladd]

On Tue, Aug 3, 2021 at 8:00 AM Ben Wilson <bwi...@mozilla.com> wrote:
>
> Chunghwa Telecom
>
> This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for Chunghwa Telecom’s request to include the HiPKI Root CA - G1 Certificate in the root store as an TLS/SSL-only root CA. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).
>

I have a number of questions related to statements in the CP and CPS
that hopefully can be cleared up. There's a number of small
infelicities,likely due to my misunderstanding or ignorance.

The CP refesr to security levels from 1 to 4. However any CA can
issue a certificate for any domain name: is there a minimum security
level CAs will be obliged to meet for signing?

In section 6.6. of the CP 2 it's stated that level 4 means Webtrust
security practices must be followed, but then in section 8 it says
that a compliannce audit with Webtrust must be conducted for every
Level 2 or higher CA. These seem at odds to me.

For the CPS of the intermediate CA I see that section 3.2.5.2 lists a
number of ways to validate domain control. I'd like to understand what
risk assessment has been done of each of these methods, some of which
seem more amenable to automation than others. There doesn't seem to be
any statement about automating this process. Section 4.2.1.1 is a bit
funny: I agree it's the right result to get the applicant to fix their
busted CAA record, and after confirming its correct issue the EV cert
(assuming all other checks went through) but it does seem a bit funny
to me in the way its worded.

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim

[Li-Chun CHEN]

Hi, Watson ,

    Please see in lines.

watso...@gmail.com 在 2021年8月5日 星期四下午1:20:15 [UTC+8] 的信中寫道：

On Tue, Aug 3, 2021 at 8:00 AM Ben Wilson <bwi...@mozilla.com> wrote:
>
> Chunghwa Telecom
>
> This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for Chunghwa Telecom’s request to include the HiPKI Root CA - G1 Certificate in the root store as an TLS/SSL-only root CA. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).
>

I have a number of questions related to statements in the CP and CPS
that hopefully can be cleared up. There's a number of small
infelicities,likely due to my misunderstanding or ignorance. 

The CP refesr to security levels from 1 to 4. However any CA can
issue a certificate for any domain name: is there a minimum security
level CAs will be obliged to meet for signing?

First of all, we have defined 4 identity assurance levels (IAL), not security levels, in HiPKI CP like NIST SP800-63, and each subscriber certificate will have a CP OID defined by CABF and may have an identity assurance level(IAL) OID arc in it. 

From HiPKI CP, Section 1.2:

If any part is not regulated under the documents of CA/Browser Forum, the rule of assurance level 1 is applicable for CAs that issue DV TLS/SSL certificates, and the rule of assurance level 3 is applicable for CAs that issue EV and OV TLS/SSL certificates. For CAs that issue self-signed, self-issued, and cross-certified certificates, the rule of assurance level 4 is always applicable.

As you can see in Sections 3.2.2 and 3.2.5 of HiPKI CP, we will made the authentication of organization identity and validation of authority prior to the issuance of any certificates. In practice, CP OIDs and certificate profile are set for each CA as a mean of asserting compliance with our HiPKI CP. 

 

In section 6.6. of the CP 2 it's stated that level 4 means Webtrust
security practices must be followed, but then in section 8 it says
that a compliannce audit with Webtrust must be conducted for every
Level 2 or higher CA. These seem at odds to me.

Thank you for your comments, we found that a paragraph was missed in Section 6.6.2 after translation from original and a typo was happened in Section 8. 

Here is the changes to these two paragraph:

(a)   In Section 6.6.2,

We will add “(4) CAs shall perform security management controls that comply with WebTrust for CA” in the right column corresponding Assurance Level 1 to 3.

(b)   In Section 8,

“The CA that issues assurance level 2 or higher certificates ...”  

will be changed to

“The CA that issues assurance level 1 or higher certificates…” 

For the CPS of the intermediate CA I see that section 3.2.5.2 lists a
number of ways to validate domain control. I'd like to understand what
risk assessment has been done of each of these methods, some of which
seem more amenable to automation than others. There doesn't seem to be
any statement about automating this process.

We have done a risk assessment, including keep pay attention to the discussions in Validation Subcommittee of the Server Certificate Working Group of CA/B Forum. These methods are acceptable methods that we think we can bear the risks after evaluation, and surely CAs need to be equipped with some verification mechanisms to prevent malicious behavior and other requests. As for domain control methods, of course we will continue to work hard to make these methods more automated in our RA system, and we have more resource to support than other CAs because our company is a domain name registrar of the base domain name and a telecommunications company as well. I think these designs are depends for each CAs where BR didn’t ask CAs to mention this and it’s real hard to do so by wording in fact.  

 

Section 4.2.1.1 is a bit
funny: I agree it's the right result to get the applicant to fix their
busted CAA record, and after confirming its correct issue the EV cert
(assuming all other checks went through) but it does seem a bit funny
to me in the way its worded.

This is a bad case, and the sentences below will be deleted in our CPS.

“If the DNS resource record of CAA exists, and has not named HiPKI EV TLS CA as the CA to authorize the issuance of the EV TLS/SSL certificate, HiPKI EV TLS CA will deem that the certificate application agrees to authorize HiPKI EV TLS CA to issue the EV TLS/SSL certificate for that complete domain name, and require the subscriber to visit the DNS for updating the DNS resource record of CAA, in order to have HiPKI EV TLS CA included in the record, and the EV TLS/SSL certificate will be issued afterwards.”

 

Thanks again for your comments, which help us a lot. 

         Li-Chun 

         Chunghwa Telecom Co., Ltd. 

[Andrew Ayer]

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

[Dean Coclin]

" 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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@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.

[Li-Chun CHEN]

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] 的信中寫道：

[Ben Wilson]

All,

I will leave the public discussion phase open in order for Chunghwa Telecom to provide an updated CPS.

Ben

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Tobias S. Josefowitz]

On Tue, Aug 24, 2021 at 6:16 PM Li-Chun CHEN <lcchen...@gmail.com> wrote:
>
> => 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.

Does this mean that

1) the dig output is parsed to determine whether the response is of
status: NOERROR or some other status
2) if a status of NOERROR is detected, the dig output is then
presented to a RAO,
3) if some other status is detected, the system skips over this step -
i.e. does not consult a RAO, but assumes issuance is permitted as far
as CAA records are concerned?

Regards,

Tobi

[Li-Chun CHEN]

Hi, Tobi,

     Please see inline.

t.jose...@gmail.com 在 2021年9月2日 星期四上午7:30:55 [UTC+8] 的信中寫道：

On Tue, Aug 24, 2021 at 6:16 PM Li-Chun CHEN <lcchen...@gmail.com> wrote:
>
> => 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.

Does this mean that

1) the dig output is parsed to determine whether the response is of
status: NOERROR or some other status

=>Yes.  

 

2) if a status of NOERROR is detected, the dig output is then
presented to a RAO,

=> Yes, our RA system logs all dig outputs that are also presented to our RAO. 

3) if some other status is detected, the system skips over this step -
i.e. does not consult a RAO, but assumes issuance is permitted as far
as CAA records are concerned?

Our RA system will made the CAA checking in accordance with Section 3.2.2.8 of the BR, and a certificate is permitted to issue if the following conditions are met:

a.      if the dig output is ‘NOERROR’ or some other status (except ‘ERROR’); and

b.     the lookup has been retried at least once; and

c.      there does not have a DNSSEC validation chain to the ICANN root.

 

Regards,

Tobi

Sincerely Yours,

           Li-Chun 

           Chunghwa Telecom  

 

[Andrew Ayer]

On Fri, 3 Sep 2021 19:40:47 -0700 (PDT)
Li-Chun CHEN <lcchen...@gmail.com> wrote:

> >
> > 3) if some other status is detected, the system skips over this
> > step - i.e. does not consult a RAO, but assumes issuance is
> > permitted as far as CAA records are concerned?
> >
>
> Our RA system will made the CAA checking in accordance with Section
> 3.2.2.8 of the BR, and a certificate is permitted to issue if the
> following conditions are met:
>
> a. if the dig output is 'NOERROR' or some other status (except
> 'ERROR'); and

"ERROR" is not a status code used
by dig as far as I can tell:
<https://gitlab.isc.org/isc-projects/bind9/-/blob/3df71614c8322ee6a0e5f2c2fff6ac11fa4f362c/lib/dns/rcode.c#L51>
Could you clarify what version of dig you are using, and what status
you are referring to? Is it the DNS RCODE?

> b. the lookup has been retried at least once; and
>
> c. there does not have a DNSSEC validation chain to the ICANN
> root.

How do you determine this? I understand that your resolver validates
DNSSEC, but when standard DNS resolvers encounter an error, they don't
report any information about DNSSEC to the client (dig in this case).
This means that dig wouldn't be able to distinguish between an error
due to an invalid DNSSEC signature (which means you absolutely must
not issue) and an externally-caused error in an unsigned zone (which
means you may issue after a retry).

You also haven't answered my earlier question of how you determine if a
failure is outside your infrastructure. In particular, how does dig
distinguish between a SERVFAIL caused by a misconfiguration in your
resolver (which means you must not issue), versus a SERVFAIL caused by a
misconfiguration in an authoritative server (which means you may issue
after a retry)?

Have you ensured that you unconditionally block issuances for all of the
Deny Tests at <https://caatestsuite.com/>?

Is the infrastructure that runs the "HiNET DNS resolver" included in the scope
of your WebPKI audits?

Regards,
Andrew

[Li-Chun CHEN]

Hi, Andrew,

Andrew Ayer 在 2021年9月4日 星期六下午10:45:21 [UTC+8] 的信中寫道：

On Fri, 3 Sep 2021 19:40:47 -0700 (PDT)
Li-Chun CHEN <lcchen...@gmail.com> wrote:


> Our RA system will made the CAA checking in accordance with Section
> 3.2.2.8 of the BR, and a certificate is permitted to issue if the
> following conditions are met:
>
> a. if the dig output is 'NOERROR' or some other status (except
> 'ERROR'); and

"ERROR" is not a status code used
by dig as far as I can tell:
<https://gitlab.isc.org/isc-projects/bind9/-/blob/3df71614c8322ee6a0e5f2c2fff6ac11fa4f362c/lib/dns/rcode.c#L51>
Could you clarify what version of dig you are using, and what status
you are referring to? Is it the DNS RCODE?

It was a typo, please ignore “(except ‘ERROR’)” part. We try to express in the previous response is that Our RA system will make CAA checking in accordance with BR 3.2.2.8, and a certificate is permitted to issue if there has no CAA record and no DNSSEC exist.

By the way, we use dig version 9.11.4 and refer to DNS RCODE. 

> b. the lookup has been retried at least once; and
>
> c. there does not have a DNSSEC validation chain to the ICANN
> root.

How do you determine this? I understand that your resolver validates
DNSSEC, but when standard DNS resolvers encounter an error, they don't
report any information about DNSSEC to the client (dig in this case).
This means that dig wouldn't be able to distinguish between an error
due to an invalid DNSSEC signature (which means you absolutely must
not issue) and an externally-caused error in an unsigned zone (which
means you may issue after a retry).

We must said that each CA would have their practices as to doing CAA lookups which would not be the same, here we just share ours.  

Taking into account the possible network delays, the lookup should be retried at least once if failure happens. If DNSSEC exists, our RA system do the following extra checks where DIP means the IP address of DNS resolvers we used:

        Using dig command “dig @DIP dnskey DOMAIN_NAME”

1.      stop checking if the status is not “NOERROR”；

2.      If there is no DNSKEY, it means that there is no DNSSEC chain, which means a CAA record lookup failure as permission to issue;

3.      If DNSKEY appears, it means there has a DNSSEC chain, another check is required:

          3.1.using dig command “dig caa @DIP +sigchase +trusted-key=./keys DOMAIN_NAME” to validate the DNSSEC chain, and our RA system treat a record lookup failure as permission to issue only if the response is “Success”.

 

That means a certificate is not permitted to issue if one of the following happens:

a.       there’s a SERVFAIL either in our DNS resolver or an authoritative server;

b.      the validity of the DNSSEC chain is expired; or

c.       unsigned zone is detected. 

 

You also haven't answered my earlier question of how you determine if a
failure is outside your infrastructure. In particular, how does dig
distinguish between a SERVFAIL caused by a misconfiguration in your
resolver (which means you must not issue), versus a SERVFAIL caused by a
misconfiguration in an authoritative server (which means you may issue
after a retry)?

With our practice, either an invalid DNSSEC signature or an externally-caused error in an unsigned zone can be detected. Like we said, a certificate is not permitted to issue if there’s a SERVFAIL either in our DNS resolver or an authoritative server. 

Have you ensured that you unconditionally block issuances for all of the
Deny Tests at <https://caatestsuite.com/>?

Yes, we have did the tests and the result shows that all these Deny Tests are blocked by our RA system. 

 

Is the infrastructure that runs the "HiNET DNS resolver" included in the scope
of your WebPKI audits?

NO,     HiNET DNS resolver is outside the scope of our WebPKI audits. 

 

Regards,
Andrew

Thanks for your comments.

Li-Chun 

Chunghwa Telecom

 

[Li-Chun CHEN]

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.

bwi...@mozilla.com 在 2021年8月25日 星期三上午3:49:11 [UTC+8] 的信中寫道：

[Ben Wilson]

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

[Ben Wilson]

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