Re: [TLS] CertficateRequest extension encoding
Geoffrey Keating <geoffk@geoffk.org> Tue, 06 September 2016 18:40 UTC
Return-Path: <geoffk@geoffk.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 8D1D012B409 for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 11:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 mAKpdRQ9pRlN for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 11:40:42 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7D112B302 for <tls@ietf.org>; Tue, 6 Sep 2016 11:40:35 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5B88833D200; Tue, 6 Sep 2016 18:40:35 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <20160904105637.sjl4wmr2hc2mito6@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaApcZBC0K8m27CtYbUd3zb5HvVQbDxpN0kkY0c=Pj4Rcw@mail.gmail.com> <CAF8qwaDVGrnzeLQD1ika0=VZbD8gJpigcRv_qgiAYdHV_iS2jA@mail.gmail.com> <CY1PR0301MB08421CDD92828E5809E40E8C8CE60@CY1PR0301MB0842.namprd03.prod.outlook.com> <CAF8qwaDj5fP_zgFruu-Q+3+Hv-=6fkJbY_k4+b9-9PcHSidqfg@mail.gmail.com> <1473171296219.4329@cs.auckland.ac.nz>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Tue, 06 Sep 2016 11:40:35 -0700
In-Reply-To: <1473171296219.4329@cs.auckland.ac.nz>
Message-ID: <m2twdsoorg.fsf@localhost.localdomain>
Lines: 26
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/W4BHwWm8jbXYWRyu7N7rgQC2Jx8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] CertficateRequest extension encoding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Sep 2016 18:40:43 -0000
Peter Gutmann <pgut001@cs.auckland.ac.nz> writes: > David Benjamin <davidben@chromium.org> writes: > > >Either way I imagine our stack will just keep on ignoring it, so I don't feel > >about this all too strongly. But the topic came up so I thought I'd suggest > >this. > > I ignore it too. Client certs are so rare, and so painful to deploy, that I'm > not going to make things harder on users by adding complex and opaque > filtering to prevent them from working. My approach is to specify as few > constraints as possible, the client submits whatever certificate it has, and > it's then decided based on a whitelist for which the server can very clearly > report "not on the whitelist" when it rejects it. The design seems to be > based on the idea that each client has a smorgasbord of certs and the server > can specify in precise detail in advance which one it wants, when in reality > each client has approximately zero certs, and the few that do have one just > want the one they've got to work. A typical macOS system will have many issued certs, typically with at most one that will work for any particular web site or web API. So the filter is somewhat important for client certs to work there in any kind of user-friendly way. In particular if the server provides no guidance, the UI will ask the user, presenting a dialog containing many certificates the user is not aware they have, leading to complete user confusion.
- [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Peter Gutmann
- Re: [TLS] CertficateRequest extension encoding Anders Rundgren
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding Geoffrey Keating
- Re: [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Andrei Popov
- Re: [TLS] CertficateRequest extension encoding Nick Sullivan
- Re: [TLS] CertficateRequest extension encoding David Benjamin
- Re: [TLS] CertficateRequest extension encoding Nick Sullivan
- Re: [TLS] CertficateRequest extension encoding Martin Thomson
- Re: [TLS] CertficateRequest extension encoding Ilari Liusvaara
- Re: [TLS] CertficateRequest extension encoding Martin Rex