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

Russ Housley <housley@vigilsec.com> Mon, 06 February 2017 19:25 UTC

Return-Path: <housley@vigilsec.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 EE3F41295C5 for <pkix@ietfa.amsl.com>; Mon, 6 Feb 2017 11:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YJhhlZXt7xff for <pkix@ietfa.amsl.com>; Mon, 6 Feb 2017 11:25:49 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00C11295DA for <pkix@ietf.org>; Mon, 6 Feb 2017 11:25:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 27E71300429 for <pkix@ietf.org>; Mon, 6 Feb 2017 14:25:43 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id otrXeKrk4wTb for <pkix@ietf.org>; Mon, 6 Feb 2017 14:25:41 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 89202300254; Mon, 6 Feb 2017 14:25:40 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20170203141815.346CAB81685@rfc-editor.org>
Date: Mon, 06 Feb 2017 14:25:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE00866B-9E4C-43E1-83C9-1A0C00F66FCF@vigilsec.com>
References: <20170203141815.346CAB81685@rfc-editor.org>
To: Phillip Hallam-Baker <philliph@comodo.com>, Rob Stradling <rob.stradling@comodo.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/qV07yOlW1J4aISrbUsZI2Ariw-0>
Cc: IETF PKIX <pkix@ietf.org>, Attila.Bruncsak@itu.int
Subject: Re: [pkix] [Technical Errata Reported] RFC6844 (4922)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Feb 2017 19:25:51 -0000

I suspect that the document says what the authors intended.  Please confirm.

Russ


On Feb 3, 2017, at 9:18 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_search.php?rfc=6844&eid=4922
> 
> --------------------------------------
> Type: Technical
> Reported by: Attila Bruncsák <Attila.Bruncsak@itu.int>
> 
> Section: 4
> 
> Original Text
> -------------
> The search for a CAA record climbs the DNS name tree from the
>   specified label up to but not including the DNS root '.'.
> 
> Corrected Text
> --------------
> The search for a CAA record must not climb the DNS name tree from the
>   specified label up.
> 
> Notes
> -----
> Obviously it does not make any sense to climb up. If there would be CAA record published for the "com" TLD, than it would make what relation to the CAA of the "example.com" domain? From an other viewpoint: all CAs are going to check the "com" TLD for CAA record if a given organization has no CAA record published in its own domain?
> Another, more practical example: "example.com" needs a certificate for his top domain (https://example.com/), so it decides to publish the CAA record to enforce the security. Doing this it may unknowingly affect the renewal of the certificate for the wellhidden.hr.example.com where the hr.example.com domain is under different administrative authority than example.com domain itself.
> 
> 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
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix