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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 03 February 2017 14:53 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 07189129DAB for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 06:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Aj33qXD0QtJV for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 06:53:42 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCCD129DA7 for <pkix@ietf.org>; Fri, 3 Feb 2017 06:53:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E76EEBE50; Fri, 3 Feb 2017 14:53:39 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zN7ZmYCbsuc; Fri, 3 Feb 2017 14:53:39 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 449C5BE4C; Fri, 3 Feb 2017 14:53:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486133619; bh=IZ/q5oWbS11mt7M3f6UbHtvZ7w5a5X68Ia69X3PzzEw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=v9UWsgO9EcLu1espuR3jYC7mIhEdLa5EqXUJk1ROhsEJ3LVFEgmVkKhNNSkJZxQtR d2pPAR0TEEoPCyyLnF3Pqri3E7r1lpPDmSmKHUr9SfV54OkLYSy9g0ovHahJxuxt71 W+xBsFHJVJHUrjYzLvzVELEvTEpp7+5CTO9GtKc8=
To: RFC Errata System <rfc-editor@rfc-editor.org>, philliph@comodo.com, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com
References: <20170203141815.346CAB81685@rfc-editor.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <b72cb558-9c0b-f312-430b-63a28a55a2bb@cs.tcd.ie>
Date: Fri, 03 Feb 2017 14:53:39 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170203141815.346CAB81685@rfc-editor.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020703010001000000040806"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/12r_UeHJmsUUxZMwKRE91WKTHms>
Cc: 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: Fri, 03 Feb 2017 14:53:45 -0000

Hi all,

That strikes me, not as an erratum, but rather as a change
request. IIRC, that specific issue was debated at the time
so the text in the RFC is not an error, no matter whether
or not one considers it a good or bad idea.

On that basis I think this ought be rejected as an erratum,
and if folks wish to fix this, they ought write an
Internet-draft that updates RFC6844 and pursue publication
of that through the normal processes. (I'd suggest the
lamps WG [1] mailing list might be a good venue for any
initial discussion as to the desirability of that kind of
thing.)

Cheers,
S.

[1] https://tools.ietf.org/wg/lamps/


On 03/02/17 14:18, RFC Errata System 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
>