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

Megan Ferguson <mferguson@amsl.com> Wed, 14 June 2017 04:33 UTC

Return-Path: <mferguson@amsl.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8767B131AF4 for <pkix@ietfa.amsl.com>; Tue, 13 Jun 2017 21:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0uEWXF2bK8O for <pkix@ietfa.amsl.com>; Tue, 13 Jun 2017 21:32:58 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54273129B18 for <pkix@ietf.org>; Tue, 13 Jun 2017 21:32:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 150FF1CA3F3; Tue, 13 Jun 2017 21:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrGOnW911j5V; Tue, 13 Jun 2017 21:32:47 -0700 (PDT)
Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id ACBA41CA399; Tue, 13 Jun 2017 21:32:47 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Megan Ferguson <mferguson@amsl.com>
In-Reply-To: <20170606140248.B1775B80C6A@rfc-editor.org>
Date: Tue, 13 Jun 2017 21:32:57 -0700
Cc: pkix@ietf.org, RFC System <rfc-editor@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3E6206A-DC9F-4BF8-8A55-13BA385155FD@amsl.com>
References: <20170606140248.B1775B80C6A@rfc-editor.org>
To: philliph@comodo.com, Stefan Santesson <stefan@aaa-sec.com>, Stephen Kent <kent@bbn.com>, ekr@rtfm.com, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, rob.stradling@comodo.com
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/XZ4zocCW00Ic9fcr8uTvjr9xZUg>
Subject: Re: [pkix] [Technical Errata Reported] RFC6844 (5029)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 04:33:00 -0000

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

On Jun 6, 2017, at 7:02 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

> 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 <philliph@comodo.com>
> 
> 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
>