Re: [TLS] CertficateRequest extension encoding

Geoffrey Keating <> Tue, 06 September 2016 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D1D012B409 for <>; Tue, 6 Sep 2016 11:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mAKpdRQ9pRlN for <>; Tue, 6 Sep 2016 11:40:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA7D112B302 for <>; Tue, 6 Sep 2016 11:40:35 -0700 (PDT)
Received: by (Postfix, from userid 501) id 5B88833D200; Tue, 6 Sep 2016 18:40:35 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Peter Gutmann <>
References: <> <> <> <> <> <>
From: Geoffrey Keating <>
Date: Tue, 06 Sep 2016 11:40:35 -0700
In-Reply-To: <>
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: <>
Cc: "" <>
Subject: Re: [TLS] CertficateRequest extension encoding
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2016 18:40:43 -0000

Peter Gutmann <> writes:

> David Benjamin <> 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.