Re: [TLS] Server behavior when client certificate does not match the request ?

Eric Rescorla <ekr@rtfm.com> Wed, 13 January 2016 00:20 UTC

Return-Path: <ekr@rtfm.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 64C311A9114 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 16:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 4Am_wz9TdMrX for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 16:20:41 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 C4DE31A9111 for <tls@ietf.org>; Tue, 12 Jan 2016 16:20:40 -0800 (PST)
Received: by mail-yk0-x236.google.com with SMTP id v14so377738803ykd.3 for <tls@ietf.org>; Tue, 12 Jan 2016 16:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LMFK8YypvqW3o+wWwK8S8EbQ4Uyk4FM9kv9GKUrRnds=; b=Fq6i86siBP12gUsKc/BX7ofriSouIUnpJ/+OVZAqppqyrNUg6ZbmsP/3fxNgGKHt/D zvLwL8+8nNpCJO/HDUMQQIVTT1Dnf99MMS8fOolVmwODQMT9ZZ13eC35SmpOTvHTSEvF 8Rytebmx2OpIBKnTb5ebFLvN5/FIyxJ8REZ+7DwabcdC9he+MWKwP6zdkYTHU/lVdLbC tLm73JRzwIsijchZnVHObjn8L82AJcfXzH2uQKsOWzw3VCuVxe6RWmWvulA8ZIwsQUd9 OqPSQtjIMKcrKfpHsiv7SOauDqyw4D/DAR4Uq59obtC1pYqJkId+WEnb3tNy+sdV+Zb4 eapg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LMFK8YypvqW3o+wWwK8S8EbQ4Uyk4FM9kv9GKUrRnds=; b=RqmOP/X9Ljxd/hlNlfjLaInEJzr86mRSg06ft9GgHUKUtFr8iimSNSzzC0Hh1ZMxFK M3u/T1/lrmGghrVijhfZ6nFT8JJhcXZVqnRrJyN/vgnE4gt0FGLG7LasRaUxJI834QYI b4RhUu3p8ZzVDMYLdRnuvvbWnsdF+Qwi6d8vCQN5zb7j868KabhukiJgd59aQxjSaUwb lmSl+KZEFVU8Oq5XH7dBsOest21csL9Bv0pus0XG6z+imkmVPwl28bddGwYSA9bPslU6 bpYMfUotk3S/pTHieuyua88KuTJC/CuTPkgwsaJUfV8Chao/nNM3chj6pE++DRMJcMv+ hxJA==
X-Gm-Message-State: ALoCoQlsvUJyQ1jVQCfXRXtjnmbCwdOfggPqi2xoJRtasYPJuCo3c87s9ArBUEQlyguItDe37GN+d74cvWtOjaqIXs9gTL91BA==
X-Received: by 10.129.38.135 with SMTP id m129mr7074445ywm.155.1452644440033; Tue, 12 Jan 2016 16:20:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Tue, 12 Jan 2016 16:20:00 -0800 (PST)
In-Reply-To: <CANOyrg9=6z0yMUwtmf=jMcVJLWYb0ZPbD-myPz=6SsJGpvP5hg@mail.gmail.com>
References: <CANOyrg9_A=GchJ+K61cPe+J=-rRq388z60psbd5SU6hC6iPpUA@mail.gmail.com> <20160112235332.GG18704@mournblade.imrryr.org> <CANOyrg9=6z0yMUwtmf=jMcVJLWYb0ZPbD-myPz=6SsJGpvP5hg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Jan 2016 16:20:00 -0800
Message-ID: <CABcZeBMwAt2L5EJzgh01oBfxHcEXSR7afQdgms921RTOuCt-yQ@mail.gmail.com>
To: Fabrice Gautier <fabrice.gautier@gmail.com>
Content-Type: multipart/alternative; boundary=001a1141618cd57c6405292c2309
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FtTY9CREyydAnxTG1z6ki__Tbxo>
Cc: "<tls@ietf.org>" <tls@ietf.org>
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
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: Wed, 13 Jan 2016 00:20:42 -0000

On Tue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier <fabrice.gautier@gmail.com>
wrote:

>
> > 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.
>
> Which does raise another interesting question when certificate_types
> and supported_signature_algorithms conflicts.


It's the intersection:

https://tools.ietf.org/html/rfc5246#section-7.4.4

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.

   -  The end-entity certificate provided by the client MUST contain a
      key that is compatible with certificate_types.  If the key is a
      signature key, it MUST be usable with some hash/signature
      algorithm pair in supported_signature_algorithms.

However, it's confusing, and so we removed certificate_types in 1.3.

-Ekr



>
> > 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 mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>