[cabfpub] DNSSEC validation for CAA record lookup failure

[Wayne Thayer]

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.

From: Public <public-bounces at cabforum.org> on behalf of Geoff Keating via Public <public at cabforum.org>
Reply-To: Geoff Keating <geoffk at apple.com>, CA/Browser Forum Public Discussion List <public at cabforum.org>
Date: Thursday, September 14, 2017 at 10:03 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170914/84f8ffa3/attachment-0003.html>