[TLS] Server behavior when client certificate does not match the request ?
Fabrice Gautier <fabrice.gautier@gmail.com> Tue, 12 January 2016 21:08 UTC
Return-Path: <fabrice.gautier@gmail.com>
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 D9FA11A1AA1 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 13:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 r3EPtX070SOJ for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 13:08:18 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0A51A891F for <tls@ietf.org>; Tue, 12 Jan 2016 13:07:36 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id g73so202048994ioe.3 for <tls@ietf.org>; Tue, 12 Jan 2016 13:07:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=5gCX8Nh/kJn40w06KnZwq7Ehx0c1hdW9N20V78cdb/Q=; b=UULvlDl4vR+A6F3cb0xEiovGvBxQrCuGNiRhWJQHx2RV/uQaOHsJeAj/euLeb6zmyo Am2gsndGSq0qr1el6emJPQpP9XGCmhKSWeeThVEayJcnHP0Ij7QLWpu4aiq/YwGOtpIR WBPQ6degGna6MVyo+SRY+o+61UOqKqPcLducym68Zj2N1IIh5J37v6RTzG0RyIRXy/BK Lrc+S7lzI8rr+ZHGOiTaVFuH1flvfBqstWuskLgktbQVUAsNVwV0rnPu4Wtw59j/OPFc 2ReAJthzZ67su7IV1sePTaNfIlD9GZjn+vE3IhL7MM/cf7M89bnzxfr2QUcNtWpz68mf ZcBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=5gCX8Nh/kJn40w06KnZwq7Ehx0c1hdW9N20V78cdb/Q=; b=eb9265q2veH10pQdcMLh49/PR5djbse6Mfb1ij6qR5lDoWyfnL7/fW3eG/Qetqh8jZ K+xvVCXQv4Bq6+xICg6RwSX6l1grjsX/qH3gMuRDe8L60GzlKdDe2FVxWzo2fhXBC6vh pUYhe97FUOgarVqh6l1tI/OCcZxD8m+8ntgNF/UbWnaWcanPYyFSC+7m71cgYGXBdCdC OxYw8gTX0O5QmnHWV3ttViAzY7T2++xV9pvl+zKYKLkoDCgTAxkJh8IARPdkjs2at9m1 IHD8eqNipmzKtE9G+Aj7pNcj4tKSTLBCJMpDTgdyLUfOElisQoywVJ2aZYvvrQM9Awtl IKdA==
X-Gm-Message-State: ALoCoQknQdGTem+WrkQneVzia7BUEaCRcOOWEuJCh9Ci52NtyGgHwyk4LapDc6pH1UTEfdx8R0BBnbPGLyXYxm/+ZZaSbT8Rxw==
X-Received: by 10.107.128.201 with SMTP id k70mr83397843ioi.3.1452632856130; Tue, 12 Jan 2016 13:07:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.14.200 with HTTP; Tue, 12 Jan 2016 13:07:16 -0800 (PST)
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Tue, 12 Jan 2016 13:07:16 -0800
Message-ID: <CANOyrg9_A=GchJ+K61cPe+J=-rRq388z60psbd5SU6hC6iPpUA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lTAqsBt5DiHThQlkNpemLRlK3fs>
Subject: [TLS] Server behavior when client certificate does not match the request ?
X-BeenThere: tls@ietf.org
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." <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 21:08:20 -0000
Hi, TLS 1.2 RFC says that a a client certificate MUST be compatible the parameters specified in the Certificate Request: key type, hash/signature algorithm and CA. If a client does not have such a compatible cert, it MUST send an empty Certificate message. 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 ? In practice, is it okay for a client to send a cert that may not be compatible with the CertificateRequest, knowing that the client cert might be selected by user action, or by an application layer above the TLS layer, and knowing that on the server side, the client cert verification might also be done a different layer, that may actually have a different idea of what an acceptable cert is than the TLS layer ? Thanks -- Fabrice
- [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