Re: [TLS] Update spec to match current practices for certificate chain order (Martin Rex) Fri, 08 May 2015 15:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D10C1A8A83 for <>; Fri, 8 May 2015 08:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FbhBfHcDU6d1 for <>; Fri, 8 May 2015 08:04:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CE421A8A89 for <>; Fri, 8 May 2015 08:04:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3DFB2B030; Fri, 8 May 2015 17:03:58 +0200 (CEST)
X-purgate-ID: 152705::1431097439-00000B48-19D04732/0/0
X-purgate-size: 2674
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id E3DFF43F1E; Fri, 8 May 2015 17:03:58 +0200 (CEST)
Received: by (Postfix, from userid 10159) id D695F1B2DE; Fri, 8 May 2015 17:03:58 +0200 (CEST)
In-Reply-To: <>
To: "Kemp, David P." <>
Date: Fri, 8 May 2015 17:03:58 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
Archived-At: <>
Cc: "" <>
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 15:04:03 -0000

Kemp, David P. wrote:
> There is nothing wrong with the client accepting a bag 'o certs that
> is 1) incomplete, 2) has extra certs, or 3) has the exact number of
> certs in the exact order needed to chain back to a server-trusted
> root, as long as the client can validate a path back to a
> client-trusted root (using either cached or fetched certs if the
> bag doesn't work).

This is the TLS WG mailing list and the TLS protocol.  You might be
confusing this discussion with PKIX and CMS.

None of what you enumerate applies to the TLS Certificate handshake
message, because this carries well-explained MUSTs.

> PKIX specifies validation requirements that
> do not require servers to send anything, and sending a full path
> with every handshake is an efficiency gain for the first connection
> but a waste for all the rest.

For PKIX (rfc5280), the building of a certification path has been EXPLICITLY
declared "out of scope", and it is pretty normal for TLS peers to not
contain any kind of path building functionality and not to know more
than "trust anchors" for verification of certificate chains provided
by peers.

What we're looking at here, is **interoperability** requirements.

> Servers can be strict in what they send by sending a server-trusted
> path in chaining order as you suggest.

This is an obvious misunderstanding of the TLS specification and the
requirements keyword MUST:

  1. MUST
   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Sending a complete and ordered certificate chain in the "certificate_list"
element of the TLS Server Certificate handshake message is not an option,

> But clients that cannot construct a valid path on their own if the
> server's doesn't satisfy them are insufficiently liberal.

Clients do not have to accomodate server that violate MUSTS.  In most cases,
it is detrimental and often dangerous to work around such protocol
violations by the peer.

And if all of what the client has is a very short list of trust anchors
(in the optimal and safe configuration just one single trust anchor),
then there is nothing besides a simple reordering and duplicate cert
elimination that a sensible client can do about a misconfigured server
that is using a defective TLS implementation.

Either the certification path presented by the server crosses through
the trust anchor(s) of the client or ends there -- then you get interop,
or it doesn't then you get interop failure.