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

Sean Turner <sean@sn3rd.com> Fri, 03 February 2017 15:48 UTC

Return-Path: <sean@sn3rd.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 4092A129450 for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 07:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 (1024-bit key) header.d=sn3rd.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 ElOSakGoZSGn for <pkix@ietfa.amsl.com>; Fri, 3 Feb 2017 07:48:42 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 EA690129437 for <pkix@ietf.org>; Fri, 3 Feb 2017 07:48:41 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id x49so42127577qtc.2 for <pkix@ietf.org>; Fri, 03 Feb 2017 07:48:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=68HOId4CVROxUp60dyhMyBPzHjuKvKQVJYYECqK7nBs=; b=RHm+4uxxnOFHAhS9hwfHkUWFmjvl4PHNmwFgPVeVjhGsqDtPq93WNduyYOKBsElGTG QvIur65Y2ZzOVkUQpqKGKCLfWoIa9JJiv5QcF9e+ktDKBa8i2O865M4usq0bto0D6ZVz McW+304jFp8lGGYi5jtzJTJYBasbPDDN+BeyQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=68HOId4CVROxUp60dyhMyBPzHjuKvKQVJYYECqK7nBs=; b=luyA5LdFoKM+KQvrPJUVNAOgCwy5hLv00OutbJO256Ax7pWjrzol70GWqRKhnS0LVS NtSObqnSP8FFrRENNYkk/orQfGRSBrxInER6JCWfBmbPxvWt1a7EH/m8oSLY/KYgfPzL 1IJtX40YZKOIj+2wwklcZsb1cnDQnuIJs0/5V4H43NNKIFxV7YY/O4uoPRO3LeZIjyFr 9vSJhST+5ZMVNySuWbrtLawjH+UW9jccU1dnKnmfKBarKEghYrUdlf3ZI+/3FGAnH/Oc e8TT8FiH99SUNAsg7mCTKnLd4cOlvk+WgXMu3sUNSYPJL+Oe+on6mZVM0WOcP9aVKxm0 BEBg==
X-Gm-Message-State: AIkVDXJ4nX8iUE6eMjypsREMx/Z08DgmHCdcHQ63NQviaXjafV4B1uV973ofBhTgZd8ZZQ==
X-Received: by 10.200.40.113 with SMTP id 46mr13220695qtr.167.1486136921048; Fri, 03 Feb 2017 07:48:41 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id z8sm24667856qkz.42.2017.02.03.07.48.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Feb 2017 07:48:39 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <b72cb558-9c0b-f312-430b-63a28a55a2bb@cs.tcd.ie>
Date: Fri, 03 Feb 2017 10:48:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2388DC5B-C9AC-4459-887C-8ACF7BCD2D13@sn3rd.com>
References: <20170203141815.346CAB81685@rfc-editor.org> <b72cb558-9c0b-f312-430b-63a28a55a2bb@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/VRw-gGhVXtqWcPKChP2yMuRc9kk>
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:48:44 -0000

Yeah I mean throwing in the 2119-like "must not” in there seems more like a change to me to.

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