Re: [TLS] sending full certificate chains in ClientCertificate
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 24 October 2017 22:47 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198413F876 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 15:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHmxV4lcPkJg for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 15:47:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855CD13F87B for <tls@ietf.org>; Tue, 24 Oct 2017 15:47:45 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B12447A330D for <tls@ietf.org>; Tue, 24 Oct 2017 22:47:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <7457.1508880403@obiwan.sandelman.ca>
Date: Tue, 24 Oct 2017 18:47:43 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: tls@ietf.org
Message-Id: <F041D8D7-3F71-4BA7-9D57-7AC95CA71154@dukhovni.org>
References: <7457.1508880403@obiwan.sandelman.ca>
To: tls@ietf.org
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pK9JhH_zcsRimqGIfr3IuzKT6RY>
Subject: Re: [TLS] sending full certificate chains in ClientCertificate
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2017 22:47:47 -0000
> On Oct 24, 2017, at 5:26 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote: > > In the browser space there has been pushback against including the trust > anchors in the Server->Browser direction, including Google's Chrome browser > complaining about unnecessary certificates, and TLS scanners. > I understand that some of this is the result of some client libraries that > could be confused (due to bugs) into validating a bogus chain if there was a > self-signed certificate in the certificates sent from the server. > > What's unclear to me if there is any kind of specification that we would be > violating if we state that we want the full chain in the Client's Certificate > extension. Full chains are just fine. Indeed per RFC7671 with DANE-TA(2) the server MUST present a full chain (including the root CA certificate) to the client when the server's TLSA record is associated with the trust anchor certificate. If you have a legitimate use case in which the relying party may not have a copy of a root CA, but can validate it if received from the peer, then requiring the transmission of root CAs is fine and natural. -- Viktor.
- [TLS] sending full certificate chains in ClientCe… Michael Richardson
- Re: [TLS] sending full certificate chains in Clie… Viktor Dukhovni