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 > >
- Re: [pkix] [Technical Errata Reported] RFC6844 (4… Stephen Farrell
- Re: [pkix] [Technical Errata Reported] RFC6844 (4… Sean Turner
- Re: [pkix] [Technical Errata Reported] RFC6844 (4… Stephen Farrell
- [pkix] [Technical Errata Reported] RFC6844 (4922) RFC Errata System
- Re: [pkix] [Technical Errata Reported] RFC6844 (4… Russ Housley