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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 03 February 2017 15:51 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 F2603129C60 for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 07:51:27 -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 P-C2NO8gtSvN for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 07:51:20 -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 11E33129D78 for <pkix@ietf.org>; Fri, 3 Feb 2017 07:51:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 212E7BE51; Fri, 3 Feb 2017 15:51:16 +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 PZLDsDwfDT-U; Fri, 3 Feb 2017 15:51:16 +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 7198DBE4C; Fri, 3 Feb 2017 15:51:15 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486137075; bh=6Z6ln6alhQ2lwVAj9RrpKz2aPdo++to/TiqAYzTeNkY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AFibBeSPLakQxy5bNJtcCNIoO70Ta4m+H8Qv5eWXpS/cITvdxwhvmhV4QgnsWDkJF yVj73TsyFN9O6YLhGm/+NPWg5WViJTd63pSioz8KBCvwf6iS//Guzm/SUlYBsMkf9G EjeFn6KyZ5zMeuQqcgIJyTQuJyyp7ijlY1DLp4H4=
To: Sean Turner <sean@sn3rd.com>
References: <20170203141815.346CAB81685@rfc-editor.org> <b72cb558-9c0b-f312-430b-63a28a55a2bb@cs.tcd.ie> <2388DC5B-C9AC-4459-887C-8ACF7BCD2D13@sn3rd.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <c3dffefc-a41f-2957-4486-09c17429b47d@cs.tcd.ie>
Date: Fri, 03 Feb 2017 15:51:15 +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: <2388DC5B-C9AC-4459-887C-8ACF7BCD2D13@sn3rd.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060707030008060204030601"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/7Ey1JVyJ3sBO4LxcMvvEudZc4A0>
Cc: Attila.Bruncsak@itu.int, Stefan Santesson <stefan@aaa-sec.com>, pkix@ietf.org, RFC Errata System <rfc-editor@rfc-editor.org>, philliph@comodo.com
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 15:51:28 -0000


On 03/02/17 15:48, Sean Turner wrote:
> Yeah I mean throwing in the 2119-like "must not” in there seems more
> like a change to me to.

Done.

S.

> 
> spt
> 
>> On Feb 3, 2017, at 09:53, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> 
>> 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
>>> 
>> 
>> _______________________________________________ pkix mailing list 
>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
> 
>