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

"Ryan Sleevi" <> Fri, 08 May 2015 04:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21FCA1A8993 for <>; Thu, 7 May 2015 21:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 MY5Bu1f3O5Iv for <>; Thu, 7 May 2015 21:51:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 52B951A8982 for <>; Thu, 7 May 2015 21:51:55 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id E0AD0678063; Thu, 7 May 2015 21:51:54 -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=+SSqgtiktkCe073/E4tYC0GtjvQ=; b=KJB3YtEif75WEWo8g T1hRGNkt88U9VFNHJ493vbVgpfak5Kg4wFy/kWOsoqVOwTqlZWrTb3IrAf6stNHW reuG+c1PDtoKccL0fWbbMFAPRe7cohhNctDtEKy3UafMybVtWCyxNv3diFwJj0gj kJ3bqp7t4oPOrLWxGaJgtGAWyI=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 9212D678062; Thu, 7 May 2015 21:51:54 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 7 May 2015 21:51:53 -0700
Message-ID: <>
In-Reply-To: <m2oalwypd8.fsf@localhost.localdomain>
References: <> <> <m2oalwypd8.fsf@localhost.localdomain>
Date: Thu, 7 May 2015 21:51:53 -0700
From: "Ryan Sleevi" <>
To: "Geoffrey Keating" <>
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] 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: Fri, 08 May 2015 04:51:56 -0000

On Thu, May 7, 2015 3:49 pm, Geoffrey Keating wrote:
>  This answers the problem of multiple certificate paths, and doesn't
>  prevent re-ordering by the client, and also allows the server to guide
>  the client to the chain it prefers, which is important in some
>  circumstances.  For example, one chain might support EV, and another
>  might be necessary for older clients, but both might be valid in some
>  clients; the server would want to guide the client to the EV chain if
>  it will work.

The problem I have with that proposal is it conflicts with RFC 4158 and
conflicts with client practice [at least, those most likely to be
encountered at the web at large, in the context of HTTPS]

That is, yes, it's true, you can totally send based on the server's
preference, but there is zero obligation for the client to respect that
preference - and indeed, no clients that support path discovery (rather
than just path building) that I've observed actually would respect such an
order. That is, they do RFC 4158 style optimizations, ranging from caching
the certificate validation path to using application-determined
preferences (ranging from issuance date, key strength, etc)

This sort of goes back to it being a change to the path building APIs to
accommodate such language - the same reason that the current MUST is

(Yes, I'm aware that libraries that simply perform path _verification_ -
notably, OS X's & iOS's Security.framework and OpenSSL & derivatives -
would implicitly respect such preferences. But they also fail fairly
miserably at dealing with the Web PKI, as evidenced by OS X's repeated
issues whenever there is a CA cross-signing or rollover, which has been
quite common the past few years, so I don't particularly consider their
behaviours emblematic of good behaviours)

Admittedly, it's harmless language from a client implementation side - but
I fear that by describing it as such, it sets up an indirect expectation
for servers and readers that clients SHOULD respect such ordering, when
there is no such requirement and it'd be even more work to do than the
current MUST.