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 <[email protected]> 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 -- 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/20f1554b-0174-436c-990b-4faba4a724ffn%40mozilla.org.
