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

Yoav Nir <> Thu, 07 May 2015 05:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 586301ACEA2 for <>; Wed, 6 May 2015 22:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PqoMk5zl10QE for <>; Wed, 6 May 2015 22:49:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2684D1ACE9E for <>; Wed, 6 May 2015 22:49:55 -0700 (PDT)
Received: by wgyo15 with SMTP id o15so32356323wgy.2 for <>; Wed, 06 May 2015 22:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w79v7UBmAtsrqbTifHjkk8HkqfwzvsbpPZHFyYqpRsg=; b=wYj8AEknZiqMtom5XwZrFyE1kRW0bzQ4OyN8sDaomQ8WrRfTQbJmtX2fIh25Lkq3T2 AbPTU/1NzXBizh7RqD6iCY1FUBqpXu+uHjF1pC1QgWuAaV4xwTsDxOVf4zu8Cn+4fYl7 +kHySFUoy1DUj8blavHnXKjTrmjONK19U1iSX1gFQ8jFa0Pmhn/BodPO6kl/TdcqXnK6 sY7f/FRbt66ujQ1qYPM8nXiY+9649lGdTeQg4say44cFNHdPRnkGolzmEM0U6lSZjACx PxsycK24hoXLIZzwq6SCHMtO1EIdzcDvEd4GNcrNJ90i1td8OHqxpoj2IhTZfUjF77eR rohQ==
X-Received: by with SMTP id et7mr3413212wib.23.1430977793761; Wed, 06 May 2015 22:49:53 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id b5sm5538325wiw.8.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 22:49:52 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 7 May 2015 08:49:21 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dave Garrett <>
X-Mailer: Apple Mail (2.2098)
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: Thu, 07 May 2015 05:49:57 -0000

Hi, Dave

> On May 7, 2015, at 6:13 AM, Dave Garrett <> wrote:
> ----------------------------------------------------------------------
>   certificate_list
>      This is a sequence (chain) of certificates.  The sender's
>      certificate MUST come first in the list.  Each following
>      certificate MUST directly certify the one preceding it.  Because
>      certificate validation requires that root keys be distributed
>      independently, the self-signed certificate that specifies the root
>      certificate authority MAY be omitted from the chain, under the
>      assumption that the remote end must already possess it in order to
>      validate it in any case.
> ----------------------------------------------------------------------
> It seems that in practice, nobody cares about that second "MUST”.

It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing code anyway.

> I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST”)

People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

> I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

SHOULD is OK, MUST would imply perfect knowledge of how the other side is configured. The root of trust may or may not be the self-signed certificate. But it’s probably always fine to omit the self-signed certificate.

> Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.

None that I can think of