From nobody Tue Jun 6 07:02:54 2017 Return-Path: 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 00C651293FD for ; Tue, 6 Jun 2017 07:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 KVESsZ0tfDyq for ; Tue, 6 Jun 2017 07:02:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6671C128DE7 for ; Tue, 6 Jun 2017 07:02:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1775B80C6A; Tue, 6 Jun 2017 07:02:48 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: philliph@comodo.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170606140248.B1775B80C6A@rfc-editor.org> Date: Tue, 6 Jun 2017 07:02:48 -0700 (PDT) Archived-At: Subject: [pkix] [Technical Errata Reported] RFC6844 (5029) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 14:02:53 -0000 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 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 nobody Tue Jun 13 21:33:02 2017 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <20170606140248.B1775B80C6A@rfc-editor.org> Date: Tue, 13 Jun 2017 21:32:57 -0700 Cc: pkix@ietf.org, RFC System Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170606140248.B1775B80C6A@rfc-editor.org> To: philliph@comodo.com, Stefan Santesson , Stephen Kent , ekr@rtfm.com, Kathleen Moriarty , rob.stradling@comodo.com X-Mailer: Apple Mail (2.1878.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 04:33:00 -0000 Greetings, Re: > This is a correction of errata 4988 and 4992.=20 Because it seems this report (EID 5029) apparently replaces EIDs 4988 = and 4992=20 (which both currently have status "Reported"), we suggest deleting them = completely,=20 rather than marking them "Rejected". The rationale is to avoid "errata = of errata=94=20 so that the errata posted are relevant to a reader of the RFC.=20 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 = wrote: > The following errata report has been submitted for RFC6844, > "DNS Certification Authority Authorization (CAA) Resource Record". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5029 >=20 > -------------------------------------- > Type: Technical > Reported by: Phillip Hallam-Baker >=20 > Section: 4 >=20 > 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. >=20 > o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >=20 > o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D > R(A(X)), otherwise >=20 > o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >=20 > o R(X) is empty. >=20 > 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. >=20 > o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >=20 > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D > CAA(A(X)), otherwise >=20 > o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >=20 > o R(X) is empty. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 >=20 From nobody Wed Jun 14 06:55:14 2017 Return-Path: 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 91BDB129516 for ; Wed, 14 Jun 2017 06:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 HZOIl_bR9a72 for ; Wed, 14 Jun 2017 06:55:07 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782871294E8 for ; Wed, 14 Jun 2017 06:55:07 -0700 (PDT) Received: (qmail 26507 invoked by uid 1004); 14 Jun 2017 13:55:03 -0000 Received: from clofcgmail2.cl.office.comodo.net (HELO clofcgmail2.cl.office.comodo.net) (10.104.70.204) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 14 Jun 2017 14:55:03 +0100 Received: (qmail 31773 invoked by uid 1012); 14 Jun 2017 13:55:03 -0000 Received: from pool-100-0-244-109.bstnma.fios.verizon.net (HELO galifrey.hallambaker.com) (100.0.244.109) (smtp-auth username philliph, mechanism plain) by clofcgmail2.cl.office.comodo.net (qpsmtpd/0.84/v0.84-169-ga857589) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Wed, 14 Jun 2017 09:55:03 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "philliph@comodo.com" In-Reply-To: Date: Wed, 14 Jun 2017 09:55:00 -0400 Cc: Stefan Santesson , Stephen Kent , ekr@rtfm.com, Kathleen Moriarty , rob.stradling@comodo.com, pkix@ietf.org, RFC System Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170606140248.B1775B80C6A@rfc-editor.org> To: Megan Ferguson X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:55:12 -0000 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 =E2=80=98correction=E2=80=99. 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 =E2=80=98Held for document = update=E2=80=99 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.=20 > On Jun 14, 2017, at 12:32 AM, Megan Ferguson = wrote: >=20 > Greetings, >=20 > Re: >> This is a correction of errata 4988 and 4992.=20 >=20 > Because it seems this report (EID 5029) apparently replaces EIDs 4988 = and 4992=20 > (which both currently have status "Reported"), we suggest deleting = them completely,=20 > rather than marking them "Rejected". The rationale is to avoid "errata = of errata=E2=80=9D=20 > so that the errata posted are relevant to a reader of the RFC.=20 >=20 > Please let us know if deletion of EID 4988 and 4992 is acceptable. >=20 > Thank you. >=20 > RFC Editor/mf >=20 > On Jun 6, 2017, at 7:02 AM, RFC Errata System = wrote: >=20 >> The following errata report has been submitted for RFC6844, >> "DNS Certification Authority Authorization (CAA) Resource Record". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5029 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Phillip Hallam-Baker >>=20 >> Section: 4 >>=20 >> 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. >>=20 >> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>=20 >> o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D >> R(A(X)), otherwise >>=20 >> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >>=20 >> o R(X) is empty. >>=20 >> 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. >>=20 >> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>=20 >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D >> CAA(A(X)), otherwise >>=20 >> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >>=20 >> o R(X) is empty. >>=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> 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 >>=20 >=20 From nobody Wed Jun 14 07:13:20 2017 Return-Path: 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 EA69812EAA5 for ; Wed, 14 Jun 2017 07:13:18 -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 3YxkmBRCnXkq for ; Wed, 14 Jun 2017 07:13:16 -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 BFFF4124217 for ; Wed, 14 Jun 2017 07:13:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 382541CA42A; Wed, 14 Jun 2017 07:13:06 -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 51DDpboDZC_O; Wed, 14 Jun 2017 07:13:06 -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 C4A201CA38B; Wed, 14 Jun 2017 07:13:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: Date: Wed, 14 Jun 2017 07:13:17 -0700 Cc: Stefan Santesson , Stephen Kent , ekr@rtfm.com, Kathleen Moriarty , rob.stradling@comodo.com, pkix@ietf.org, RFC System Content-Transfer-Encoding: quoted-printable Message-Id: <00A0A2FA-EB1E-4BCC-A51B-054DC05A3EB2@amsl.com> References: <20170606140248.B1775B80C6A@rfc-editor.org> To: philliph@comodo.com X-Mailer: Apple Mail (2.1878.6) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:13:19 -0000 Greetings, Thank you for your reply. We have removed EIDs 4988, 4992, and 5029 as = requested. =20 RFC Editor/mf On Jun 14, 2017, at 6:55 AM, philliph@comodo.com wrote: > 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 =91correction=92. So I am = currently trying to work out some way to get them to make it final. >=20 > 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. >=20 >=20 > 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. >=20 > I would then like to get the fix into =91Held for document update=92 = state as soon as possible. >=20 >=20 > 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.=20 >=20 >=20 >> On Jun 14, 2017, at 12:32 AM, Megan Ferguson = wrote: >>=20 >> Greetings, >>=20 >> Re: >>> This is a correction of errata 4988 and 4992.=20 >>=20 >> Because it seems this report (EID 5029) apparently replaces EIDs 4988 = and 4992=20 >> (which both currently have status "Reported"), we suggest deleting = them completely,=20 >> rather than marking them "Rejected". The rationale is to avoid = "errata of errata=94=20 >> so that the errata posted are relevant to a reader of the RFC.=20 >>=20 >> Please let us know if deletion of EID 4988 and 4992 is acceptable. >>=20 >> Thank you. >>=20 >> RFC Editor/mf >>=20 >> On Jun 6, 2017, at 7:02 AM, RFC Errata System = wrote: >>=20 >>> The following errata report has been submitted for RFC6844, >>> "DNS Certification Authority Authorization (CAA) Resource Record". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5029 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Phillip Hallam-Baker >>>=20 >>> Section: 4 >>>=20 >>> 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. >>>=20 >>> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>>=20 >>> o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D >>> R(A(X)), otherwise >>>=20 >>> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >>>=20 >>> o R(X) is empty. >>>=20 >>> 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. >>>=20 >>> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>>=20 >>> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D >>> CAA(A(X)), otherwise >>>=20 >>> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise >>>=20 >>> o R(X) is empty. >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 =20 >>> can log in to change the status and edit the report, if necessary.=20= >>>=20 >>> -------------------------------------- >>> 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 >>>=20 >>=20 >=20 From nobody Sun Jun 18 22:42:50 2017 Return-Path: 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 D173D1287A5 for ; Sun, 18 Jun 2017 22:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Jkaxmgz7Cadg for ; Sun, 18 Jun 2017 22:42:46 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD25B12894A for ; Sun, 18 Jun 2017 22:42:45 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id m125so68923695wmm.1 for ; Sun, 18 Jun 2017 22:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=VFC6OlmG3rEbUomdzLaaeSRTtIAZNFEFKxP3LthH6jtRnWXo7uY3IGWjUqzoCWk4PR NvIX0I0FHzgRS+ysIdH2lrWrtynNVAU3luEEWr2TFETuKgXXvRkgmkvY7OKOqaTPSC1W ZwsWJWiA/jKoNCA7/avRy18+WeKLVaX0jXLndAkIWczncGi6vFnrLoJjrlq2NCu+UD3J bUI4uR8iAN6wBDWJRCszsk1wY4TBMvIl3zQbMeJQI0oL9dfxwK1Qj/Z7Lg21FLb/j7NE Xrr7dR7W35m7RLe1vNP8UPb2N6qSC6Gn2RL1UOaPapB5uQiLbVK9424gQSo/gMNWcEeZ 6A5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=rbgW24JWqLGJgD55KvySZ2jGPwyNW9d+GguBrqs0bxBzIZSFR2T8UWr5K22vydYYUI 3J/CtN11C3pSDCgf1Xz4wI32vn7jzxlJSbiZzNmhX3/7Rkrn4plUv61yZeCMi0ttbPf0 Gsw3XwkJAaBfFCFEmFzLf7Kqgd1DVs3SGkNgrXLfAI+Bjgkptnzmw9aNE27dgZW0QXOD 6qzpcvhCLVEKlgYXHRfNifeWTfjDbTmayWWClZLj0Izdhe0VQb2Yb59O8vEyflDtkoAT mL/epwj6+jGWxgTorOjQ1Afb0w8urt3dTLFsesmRUClcU+Mn/YF4MtabodtkHVX38CLg UxXQ== X-Gm-Message-State: AKS2vOz5TEHbdyQyWCEQyvgRwrnx5DYXHz6uif6niMInd1HtqOiqMyWL z3TgiyF5p3baZV4U X-Received: by 10.28.222.195 with SMTP id v186mr13547896wmg.88.1497850964286; Sun, 18 Jun 2017 22:42:44 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id p87sm14117604wma.2.2017.06.18.22.42.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jun 2017 22:42:43 -0700 (PDT) From: Anders Rundgren To: "pkix@ietf.org" Message-ID: Date: Mon, 19 Jun 2017 07:42:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] RFC: Java support for CURDLE X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 05:42:48 -0000 https://github.com/bcgit/bc-java/issues/193#issuecomment-309183825 Anders