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

Viktor Dukhovni <> Tue, 12 May 2015 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 986B11A90E5 for <>; Tue, 12 May 2015 09:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Oss1ANTQdyx for <>; Tue, 12 May 2015 09:24:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07B161A9235 for <>; Tue, 12 May 2015 09:24:06 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 613D8283031; Tue, 12 May 2015 16:24:05 +0000 (UTC)
Date: Tue, 12 May 2015 16:24:05 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 16:24:08 -0000

On Fri, May 08, 2015 at 08:51:49PM -0700, Ryan Sleevi wrote:

> I know nothing I say will dissuade you from calling it "unsafe path
> discovery", even though I rather vehemently disagree with you. I will
> simply point out, however, that were it not for this "unsafe path
> discovery", we would not finally be moving to a place where we might be
> able to turn off 1024-bit RSA keys used in intermediate and root
> certificates, because the PKI is hard and the Internet involves multiple
> stakeholders.

FWIW, OpenSSL does no path discovery.  Whatever certificates the
server sends, there is a linearly ordered subset[1] of these that
achieves the same validation result as the original heap of certs
for all OpenSSL-based clients.  So sending something other than a
linearly ordered list has no value.

With OpenSSL 1.0.2 recently tweaked to do trust-store look-asides
for nodes in the middle of the provided linear list, as also noted
by Martin cross-signing with SHA256 or RSA 2048, ... works just


[1] If we assign ordinals to the heap elements in order of appearance,
the equivalent linear list is the chain (successor == issuer of
predecessor) that sorts lexically first.  That is for each chain
element, the issuer with the smallest heap ordinal is chosen and
no other issuers from the heap are considered.

This is augmented with look-aside at each chain layer into the
trust store, to identify a locally trusted alternative issuer.