<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2017, at 10:02 AM, Geoff Keating via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">At the moment the BRs say:<div class=""><br class=""></div><div class="">
<div class="page" title="Page 24">
<div class="layoutArea">
<div class="column"><p class=""><span style="font-size: 10.000000pt; font-family: 'Cambria'" class="">CAs are permitted to treat a record lookup failure as permission to issue if:
</span></p>
<ul class="">
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the failure is outside the CA's infrastructure;
</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the lookup has been retried at least once; and
</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the domain's zone does not have a DNSSEC validation chain to the ICANN root. </span></p>
</li>
</ul>
</div>
</div>
</div></div><div class="">I suggest replacing the last item with “the record being looked up is classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”</div><div class=""><br class=""></div><div class="">The most common case of this will be that the record being looked up is a CAA record for, say, <a href="http://example.com/" class="">example.com</a>; the .com servers have been contacted successfully, producing authenticated NS records for <a href="http://example.com/" class="">example.com</a>, but the <a href="http://example.com/" class="">example.com</a> name servers cannot be contacted; and the .com servers have provided authenticated denial of existence for a DS record for <a href="http://example.com/" class="">example.com</a>. This is covered in RFC 4035 section 5.2, “If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child.”</div></div></div></blockquote><br class=""></div><div>Geoff,</div><div><br class=""></div><div>This covers the “affirmatively insecure” case — that is a signed response affirmatively indicates there are no DS records for a given name but there are NS records for the same name.</div><div><br class=""></div><div>However many of the cases are not as clear, especially in the face of NSEC3 with opt-out. What if there is a DS record but the child zone returns an answer that is covered in an opt-out gap? What if the delegation without DS is covered in opt-out? Are these both affirmatively insecure?</div><div><br class=""></div><div>Also, take a look at <a href="https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439" class="">https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439</a> There is discussion there that highlights another challenge: what happens in error cases. How should CAs handle a case where they are trying to get data for <a href="http://beta.shop.example.com" class="">beta.shop.example.com</a>, <a href="http://example.com" class="">example.com</a> has a DS record in the com zone, but there are no DNSKEY records for <a href="http://example.com" class="">example.com</a> in the <a href="http://example.com" class="">example.com</a> zone? We don’t know if <a href="http://shop.example.com" class="">shop.example.com</a> is insecure or secure.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><div><br class=""></div><div><br class=""></div><div><br class=""></div></body></html>