Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 22:03 UTC

Return-Path: <ryan-ietftls@sleevi.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204871AD358 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 15:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 JY1sxf_Sx0zT for <tls@ietfa.amsl.com>; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E6ABA1AD356 for <tls@ietf.org>; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id A2E9F6740D9; Tue, 12 May 2015 15:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=tvEOo9JN6YeFOQNDZ4MGR0Av61M=; b=fCiXg2xnEFPv8F+vd Rw1/hNc1lKA1e5dmwLP5Ml3o76gGyoSdbs/2hizL2w9Z8vKULqPyXlpsBvXU56Ca um1fNdyTaTjXmFE0RX8x5L9PIHCuXsgQ+475Hso3Wh1hFQFgXUfgnMymAlctzz04 UWrtvdqajEvzbvMQnBD4rD7y2A=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 3145767409D; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 15:03:16 -0700
Message-ID: <a1f9df1a5eb595e4307984c6971e1152.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150512213853.435ED1B2EB@ld9781.wdf.sap.corp>
References: <20150512213853.435ED1B2EB@ld9781.wdf.sap.corp>
Date: Tue, 12 May 2015 15:03:16 -0700
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
To: mrex@sap.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kC5EYYoOgMDWn7uLGmRrKOgavM8>
Cc: tls@ietf.org
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ryan-ietftls@sleevi.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 22:03:18 -0000

On Tue, May 12, 2015 2:38 pm, Martin Rex wrote:
>  One of the worst problems in your proposed text is the replacment
>  of the term "self-signed [...] root certificate authority" with
>  two bogus occurrences of the term "trust anchor".
>
>  Trust anchor is a _strictly_ local concept, so this term
>  MUST NOT be used in the description of the TLS Certificate PDU.
>
>  self-signed root certificate authority is a simple technical term,
>  that does *NOT* imply trust by any party.
>
>  -Martin
>

Martin,

You will find the reasoning already provided in past messages for why this
proposed terminology change. "self-signed root certificate authority" is,
unquestionably, NOT a simple technical term (considering how many times it
has confused people, I should think this obvious). Please do re-read the
message is which I provided the justification for this change, and
hopefully provide counter-factual evidence if there is any.

Considering that "trust anchor" is a term extensively used in RFC 5280, I
also fail to understand your objection about it being a "local only"
concept. This is entirely in line with the current language where you can
omit certificates that you know your peer does not need.

I'm happy to work to resolve the objections, but I can't help but feel
like some, like this, aren't well justified or supported.