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

Viktor Dukhovni <> Thu, 07 May 2015 15:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 99A201ACD07 for <>; Thu, 7 May 2015 08:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ai7s0P_-EUz for <>; Thu, 7 May 2015 08:52:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C70CB1ACCF9 for <>; Thu, 7 May 2015 08:51:49 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 2E1CB283031; Thu, 7 May 2015 15:51:48 +0000 (UTC)
Date: Thu, 7 May 2015 15:51:48 +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: Thu, 07 May 2015 15:52:09 -0000

On Thu, May 07, 2015 at 02:43:45PM +0000, Peter Gutmann wrote:

> >PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify
> >the end-entity certificate.  In TLS, the identification is the first position
> >in certificate_list.  So it is not possible to "blindly reuse" the code with
> >respect to identifying the end-entity certificate.
> Yes it is, as I mentioned in my previous message my code looks for the server
> FQDN/whatever and uses the cert that contains that as the leaf cert.  It's the
> same process that's used for IssuerAndSerialNumber, SCEP client IDs, and
> various other things, "find the cert for the identified party, then follow
> parent links to build the chain".

I don't see such an ad-hoc approach as a compelling reason to remove
the requirement that the end-entity certificate must come first.  The
MUST needs to stay.

The TLS layer does not always know which SAN value will be used to
authenticate the peer.  Certificate verification can be delayed
until the handshake is complete, and can be performed outside the
TLS stack.  The TLS stack needs the leaf certificate for key

I summary, the only thing that could be tweaked is the requirement
to order the intermediate certificates.  The first MUST and final
MAY are correct as they stand.  And I think that the second MUST
is a fine example of Postel's principle.  Tolerance by many clients
of servers that ignore the requirement does not invalidate the