Re: [TLS] Update spec to match current practices for certificate chain order (Martin Rex) Sat, 09 May 2015 03:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A7FC1A8A7E for <>; Fri, 8 May 2015 20:20:40 -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 JozKKle1VHT0 for <>; Fri, 8 May 2015 20:20:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3415D1A8A67 for <>; Fri, 8 May 2015 20:20:38 -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 3645C2AF60; Sat, 9 May 2015 05:20:36 +0200 (CEST)
X-purgate-ID: 152705::1431141636-00005316-235CB2E8/0/0
X-purgate-size: 1741
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 11E1743E70; Sat, 9 May 2015 05:20:36 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 072AD1B2E2; Sat, 9 May 2015 05:20:36 +0200 (CEST)
In-Reply-To: <>
To: Dave Garrett <>
Date: Sat, 9 May 2015 05:20:35 +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: <>
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 03:20:40 -0000

Dave Garrett wrote:
> A PR with language based on this discussion:
> The text is mostly the same or similar, with the second "MUST" changed
> to a "SHOULD", and the term "trust anchor" replacing references to root
> keys/CA.
> Is this changeset acceptable?

I am violently opposed to this change.

It creates new ambiguities, makes bogus, backwards-incompatible
and interoperability-impairing behaviour appear less objectionable,
while providing _zero_ benefit.

The "original" requirements apply to the server's Certificate
handshake message, i.e. which certificates and in what order the
server is required to encode into the Server Certificate handshake

The purpose of these requirements for the server is to facilitate
the the client's job to verify the server's certificate, improve
interoperability and create a predictable&deterministic client
behaviour that should be independent from the particular client
implementation as much as possible.

Clients that are willing to perform unsafe path discovery on
a Server's certificate handshake message will *NOT* be inconvenienced
if the server puts the certificates in correct order and optionally
omits only the self-signed rootCA certificate at the end.

Clients that do not perform any fancy unsafe path discovery, on the
other hand, may easily be non-interoperable with sloppy servers that
do not properly compose their Server Certificate handshake message,
and these Client are _not_ to blame for any resulting interop failure,
because it is clearly the server TLS implementation that goofed
when it produces a Server Certificate PDU that violates the MUSTs.