> On 14 Sep 2017, at 12:11 pm, Wayne Thayer via Public <[email protected]> > wrote: > > Thanks Geoff. To be clear, does your proposed language require > ‘authentication of an NSEC RRset that proves that no DS RRset is present for > this zone’ in order to meet the new condition of the last item, or can an > unauthenticated query that returns no DS record be used to meet this > condition? If the former, then I wonder if the work to implement this is much > different than requiring full support for DNSSEC.
I don’t think we’re trying to require DNSSEC validation, so an unauthenticated query would be evidence. I do draw your attention to RFC 6840, which clarifies some details, in particular section 4.4 explains the need to check that there’s a NS record served by the same servers that deny existence of a DS record. > From: Public <[email protected]> on behalf of Geoff Keating via > Public <[email protected]> > Reply-To: Geoff Keating <[email protected]>, CA/Browser Forum Public > Discussion List <[email protected]> > Date: Thursday, September 14, 2017 at 10:03 AM > To: CA/Browser Forum Public Discussion List <[email protected]> > Subject: [cabfpub] DNSSEC validation for CAA record lookup failure > > At the moment the BRs say: > > CAs are permitted to treat a record lookup failure as permission to issue if: > the failure is outside the CA's infrastructure; > the lookup has been retried at least once; and > the domain's zone does not have a DNSSEC validation chain to the ICANN root. > I suggest replacing the last item with “the record being looked up is > classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.” > > The most common case of this will be that the record being looked up is a CAA > record for, say, example.com <http://example.com/>; the .com servers have > been contacted successfully, producing authenticated NS records for > example.com <http://example.com/>, but the example.com <http://example.com/> > name servers cannot be contacted; and the .com servers have provided > authenticated denial of existence for a DS record for example.com > <http://example.com/>. 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." > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
