[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