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

Viktor Dukhovni <> Thu, 07 May 2015 06:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E53FE1AD34F for <>; Wed, 6 May 2015 23:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.186
X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, J_CHICKENPOX_21=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AvL3mtdzrrKI for <>; Wed, 6 May 2015 23:59:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CDD61AD2C4 for <>; Wed, 6 May 2015 23:59:26 -0700 (PDT)
Received: by (Postfix, from userid 1034) id E61AE283031; Thu, 7 May 2015 06:59:24 +0000 (UTC)
Date: Thu, 7 May 2015 06:59:24 +0000
From: Viktor Dukhovni <>
Message-ID: <>
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: Thu, 07 May 2015 06:59:28 -0000

On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote:

> > 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)

Sorry, this is incompatible with use of DANE TLSA records when the
ceritificate usage is DANE-TA(2).  See:

The first of these is currently in IETF LC, the second in DANE WG LC.

> SHOULD is OK, MUST would imply perfect knowledge of how the other side is
> configured.

As you note, there is more than one way to verify certificates,
and the server cannot know exactly which certificates are needed
by the client.  A SHOULD or MUST would be counter-productive.

> 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.

No, not always.

> > 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

You won't be able to say that next time. :-)