Subject: [pkix] [Technical Errata Reported] RFC6844 (5029)

From: RFC Errata System <[email-masked]>
Date: Tue, 6 Jun 2017 07:02:48 -0700 (PDT)

The following errata report has been submitted for RFC6844,
"DNS Certification Authority Authorization (CAA) Resource Record".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5029

--------------------------------------
Type: Technical
Reported by: Phillip Hallam-Baker <[email-masked]>

Section: 4

Original Text
-------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

Corrected Text
--------------
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record to its target. If the target label contains a
  CAA record, it is returned. otherwise, the CA continues the search at
  the parent of node X.

  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).

  If the target of a CNAME record is itself a CNAME record, the CA MAY
  follow it or MAY ignore it. In either case, the search continues at
  the parent of the label containing the initial CNAME.

  Processing for DNAME is exactly the same as for CNAME. Note that since
  DNAME records are implemented by creating the corresponding CNAME
  records on the fly, it is only necessary for DNAME records to appear
  on the wire for purposes of DNSSEC.

Notes
-----
This is a correction of errata 4988 and 4992. It is a breaking change albeit one that is consistent with the text of the following example rather than the algorithm specification. The algorithm described in this errata is the algorithm currently implemented in running code.

A separate proposal is being made to change the discovery process. It is thus expected that a new RFC will be issued in due course but not necessarily describing the algorithm shown here.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6844 (draft-ietf-pkix-caa-15)
--------------------------------------
Title               : DNS Certification Authority Authorization (CAA) Resource Record
Publication Date    : January 2013
Author(s)           : P. Hallam-Baker, R. Stradling
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Megan Ferguson <[email-masked]>
Date: Tue, 13 Jun 2017 21:32:57 -0700

Greetings,

Re:
> This is a correction of errata 4988 and 4992. 

Because it seems this report (EID 5029) apparently replaces EIDs 4988 and 4992 
(which both currently have status "Reported"), we suggest deleting them completely, 
rather than marking them "Rejected". The rationale is to avoid "errata of errata” 
so that the errata posted are relevant to a reader of the RFC. 

Please let us know if deletion of EID 4988 and 4992 is acceptable.

Thank you.

RFC Editor/mf

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 14 Jun 2017 09:55:00 -0400

OK so the situation is currently as follows. Each time I have submitted an errata, I have circulated the text for review first and got the folk who raised the objection to clear it. Then 6 hours after i submit the update, they come with yet another ‘correction’. So I am currently trying to work out some way to get them to make it final.

We are now looking at the exact wording of how to follow CNAME. Everyone who read it found RFC 1034 to be clear on that point, they just disagree on what it says.

At this point please delete 4988, 4992 and 5029. I will attempt to get them to agree on wording for a replacement under the understanding that there is not going to be a fifth.

I would then like to get the fix into ‘Held for document update’ state as soon as possible.

We did discuss the issue in LAMPS and there is interest in considering an update to the processing rules there. However, someone suggested a completely different approach which happens to be a lot better. So it is probably not just going to be a matter of copying the errata text into the RFC. 

> On Jun 14, 2017, at 12:32 AM, Megan Ferguson <[email-masked]> wrote:
> 
> Greetings,
> 
> Re:

---

From: Megan Ferguson <[email-masked]>
Date: Wed, 14 Jun 2017 07:13:17 -0700

Greetings,

Thank you for your reply.  We have removed EIDs 4988, 4992, and 5029 as requested.  

RFC Editor/mf