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

Viktor Dukhovni <> Sat, 09 May 2015 05:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4D001A910F for <>; Fri, 8 May 2015 22:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zmBRgBY2TF5O for <>; Fri, 8 May 2015 22:34:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D35D1A910E for <>; Fri, 8 May 2015 22:34:04 -0700 (PDT)
Received: by (Postfix, from userid 1034) id F14F4283031; Sat, 9 May 2015 05:34:02 +0000 (UTC)
Date: Sat, 9 May 2015 05:34:02 +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: Sat, 09 May 2015 05:34:09 -0000

On Sat, May 09, 2015 at 12:49:16AM -0400, Dave Garrett wrote:

> > It creates new ambiguities, makes bogus, backwards-incompatible
> > and interoperability-impairing behaviour appear less objectionable,
> Yep, but it does convert interoperability-impairing behavior into interoperable behavior.

On the contrary, the currently required server behaviour is
interoperable, and relaxing the rules is likely to reduce that
interoperability if more servers violate the rules.

The fact that many clients don't enforce the rules is not surprising,
there is no Internet protocol police, and the spec does not require
clients to enforce the rules.

We must read the spec exclusively as a server requirement to order
the chain.  Client obligations in particular TLS applications may
vary from application to application.  Browsers may well jump
through various hoops, and likely need to do so.  Other applications
do not.  The world-wide-web is not the entire Internet, and browsers
are not the only TLS-using applications.

For example, Postfix (when configured to validate peer certificates
via a set of local trust-anchors) does not tolerate missing
intermediate certificates, the trust store it uses for this typically
contains only self-signed trust-anchor certs.

Yes, I know that the specific change of language is only about
certificate order, and does not remove the requirement to send all
the requisite certs.  And in fact Postfix does tolerate out-of-order
intermediates (because OpenSSL does).  So my example is but an
analogy, and does not *specifically* warrant retaining the order
constraint, but other clients may be even more constrained, and
that's OK for those particular applications.

Nothing in the current server requirement precludes any client
accomodations for servers that don't send the requisite chain.
When those are appropriate, they can be employed.