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

"Ryan Sleevi" <> Tue, 12 May 2015 22:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 204871AD358 for <>; Tue, 12 May 2015 15:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JY1sxf_Sx0zT for <>; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E6ABA1AD356 for <>; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A2E9F6740D9; Tue, 12 May 2015 15:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s=; bh=tvEOo9JN6YeFOQNDZ4MGR0Av61M=; b=fCiXg2xnEFPv8F+vd Rw1/hNc1lKA1e5dmwLP5Ml3o76gGyoSdbs/2hizL2w9Z8vKULqPyXlpsBvXU56Ca um1fNdyTaTjXmFE0RX8x5L9PIHCuXsgQ+475Hso3Wh1hFQFgXUfgnMymAlctzz04 UWrtvdqajEvzbvMQnBD4rD7y2A=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 3145767409D; Tue, 12 May 2015 15:03:16 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Tue, 12 May 2015 15:03:16 -0700
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Tue, 12 May 2015 15:03:16 -0700
From: Ryan Sleevi <>
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: <>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


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.