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

"Kemp, David P." <> Fri, 08 May 2015 14:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 973A41A893B for <>; Fri, 8 May 2015 07:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dQI3RYOV9cqQ for <>; Fri, 8 May 2015 07:51:14 -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 92C241A895E for <>; Fri, 8 May 2015 07:51:13 -0700 (PDT)
Received: from ( []) by with ESMTP id t48EpAuK030925 for <>; Fri, 8 May 2015 10:51:10 -0400 (EDT)
Received: from ([fe80::60c7:cec6:b35c:deed]) by ([::1]) with mapi id 14.03.0210.002; Fri, 8 May 2015 10:51:10 -0400
From: "Kemp, David P." <>
To: "" <>
Thread-Topic: [TLS] Update spec to match current practices for certificate chain order
Thread-Index: AQHQiZn8GsXTU1lDEU6QPCBLhUKLhZ1yJW3w
Date: Fri, 8 May 2015 14:51:09 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Fri, 08 May 2015 14:51:16 -0000

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

Servers can be strict in what they send by sending a server-trusted path in chaining order as you suggest.   But clients that cannot construct a valid path on their own if the server's doesn't satisfy them are insufficiently liberal.

-----Original Message-----
From: TLS [] On Behalf Of Martin Rex
Sent: Friday, May 08, 2015 10:19 AM
To: Dave Garrett
Subject: Re: [TLS] Update spec to match current practices for certificate chain order

Dave Garrett wrote:
> On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote:
>> Personally, I find it quite appalling how many broken TLS 
>> implementations out there fail to properly encode an ordered list of 
>> certificates into the Certificate handshake message.
> or more concisely:
> On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
>> Bleh.
> I think we're in fair agreement that this is sloppy, but it's 
> sloppiness that should've been fixed long ago if we still wanted to fight it.
> I brought this issue up in response to a bug report for Firefox fully 
> validating an EV cert list with an extra cert and things out of order.
> Mozilla and others seem to accept it just fine, so either the spec 
> needs updating to reality or everyone should be adding new security 
> errors to break it. The former makes more sense.

No, the former is clearly detrimental.

Browsers, which haved added fancy colors and stuff to address bars for EV certs, really ought to punish servers sending bogus Certificate handshake messages by reducing the color feedback to mere black&white and not attributes (_not_ produce a warning!  I believe the Google Chrome 42 behaviour for sha1-Signatures is totally wrong, because hardly anyone understands what the real issue is, and Chrome will not tell you which signature algorithms in which certs it is unsatisfied with).

I believe that one of the causes why the problem exists at all is a lack of sensible PKI credential management on the server side.

Properly done, the PKI software on the server side will refuse installation of a server certificate with an incomplete certification path directly to the administrator who is trying to install the certificate.
The only person who can "fix" such a configuration error is the server admin, so the admin (a) should get to see that error and (b) get to see it upfront, even before starting a server with a bogus configuration.

After successful server certificate chain verification (normally on maintenance operations on a server's PKI credential, or for servers lacking PKI credentials management, at least once on server start) the correct ordering of certificates is known, and that known ordering can then be used for thousands/millions of TLS handshakes without wasting any further CPU cycles.


TLS mailing list