Re: [TLS] Update spec to match current practices for certificate chain order

Ilari Liusvaara <> Tue, 12 May 2015 12:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 633891ACD07 for <>; Tue, 12 May 2015 05:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3zVfr2Fvojcu for <>; Tue, 12 May 2015 05:22:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 177A41ACC8A for <>; Tue, 12 May 2015 05:22:56 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 8D6DD8191C; Tue, 12 May 2015 15:22:54 +0300 (EEST)
Date: Tue, 12 May 2015 15:22:54 +0300
From: Ilari Liusvaara <>
To: Dave Garrett <>
Message-ID: <20150512122254.GA2287@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
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 12:22:59 -0000

On Fri, May 08, 2015 at 07:35:13PM -0400, Dave Garrett wrote:
> A PR with language based on this discussion:
> The text is mostly the same or similar, with the second "MUST" changed
> to a "SHOULD", and the term "trust anchor" replacing references to
> root keys/CA.
> Is this changeset acceptable?

What's the point of this change? To allow server to send multiple
certificate chains (all starting from one EE cert) at once?

If it is that, why isn't topological ordering still required to
be correct (certificates signed preceed certificates signing)?

And does this proposed change allow server to send incomplete
certificate chains? According to SSL Pulse (May 2015), about
5% of servers have incomplete chains, and it is marked as a

Also, regarding "chain-building", one has to be careful with its
interaction with HPKP, which is currently as-deployed the _only_
mechanism that can be usefully used to harden a site against
misissued certificates (too bad it is qute a footgun, especially
due to chain rewriting).