Re: [TLS] Server behavior when client certificate does not match the request ?
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 12 January 2016 23:53 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA161A90AA for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 15:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 ztHg0LEO90a8 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 15:53:34 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7621A90A5 for <tls@ietf.org>; Tue, 12 Jan 2016 15:53:33 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C5B0C284F1B; Tue, 12 Jan 2016 23:53:32 +0000 (UTC)
Date: Tue, 12 Jan 2016 23:53:32 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20160112235332.GG18704@mournblade.imrryr.org>
References: <CANOyrg9_A=GchJ+K61cPe+J=-rRq388z60psbd5SU6hC6iPpUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANOyrg9_A=GchJ+K61cPe+J=-rRq388z60psbd5SU6hC6iPpUA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/po6Nf8Pv6DTUx3Y1vPBoDnRyil0>
Subject: Re: [TLS] Server behavior when client certificate does not match the request ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 12 Jan 2016 23:53:35 -0000
On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > In practice, what is a common behavior for Servers in the case where > the client sends an incompatible cert ? Treat it as if there was an > empty cert or an invalid cert ? Fail the handshake ? With TLS 1.0/1.1, in which the server cannot indicate support for a list signature algorithms, the logical conclusion is that the client MUST NOT use a public key algorithm that is different from the agreed cipher-suite. It can accomplish this by only advertising cipher suites compatible with the client certificate it will (can be tricky if it has more than one). With TLS 1.0/1.1 there is no reason to expect that the server will understand signatures made with a public key algorithm other than the one used in the the server certificate (which agrees with the ciphersuite in the server HELLO). With TLS 1.2, where the server does send a supported_signature_algorithms list, clients that use signatures other than those listed should expect to run into servers that reject this with a fatal alert. The server's TLS stack (not its X.509 chain verification code) has to check the signature in the client's "Certifice Verify" message. The server's list of CA's on the other hand is largely a hint, and clients often just ignore it entirely. If the server can verify the certificate, it generally does not matter whether the CA was listed in the certificate request message or not. For many servers client certificates are optional anyway, or they verify them without reference to any particular PKI. -- Viktor.
- [TLS] Server behavior when client certificate doe… Fabrice Gautier
- Re: [TLS] Server behavior when client certificate… Eric Rescorla
- Re: [TLS] Server behavior when client certificate… Fabrice Gautier
- Re: [TLS] Server behavior when client certificate… Eric Rescorla
- Re: [TLS] Server behavior when client certificate… Peter Gutmann
- Re: [TLS] Server behavior when client certificate… Viktor Dukhovni
- Re: [TLS] Server behavior when client certificate… Fabrice Gautier
- Re: [TLS] Server behavior when client certificate… Eric Rescorla