IETF Logo Mail Archive

Re: [TLS] CertficateRequest extension encoding

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 06 September 2016 14:15 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 BAE6D12B37A for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 07:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Level:
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 JkDWw7-tVM8l for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 07:15:28 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534C312B1F4 for <tls@ietf.org>; Tue, 6 Sep 2016 07:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1473171328; x=1504707328; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7vs8O2tPak1u+Az08bVZeI1ZQ76aGuznfba57B1CA6s=; b=ScK6EqfR6K8o3T5NGuIjQuY0FFkXhg46RF46G29xsY1W/nI1rWfralsi JCp2VTzqQNbZDJtlU6v093/mPQ+qS5UcivejXUcdbT+LDdz8f9mgT8nXg oT8yqN+TIRjWzsRmF6/cv9D9lUuMJ373azz+kMDC24vhMi5aSc+2JhuRN lbCNQeBbh4MJJKDE2i39ExallyudXNdVS+GYhmiHlINJU7dQtcVr8fu7W lGinbMYbS1CcW8X+dhsbz4K6432+J1RssVJ0Uaz4ocY3pWcbR7NArXEKE ITBnjmEK+CIBk3DO2NIkPRddQqqLQ0+nkgsvkjI17xOwcDawup6sT7RKM w==;
X-IronPort-AV: E=Sophos;i="5.30,291,1470657600"; d="scan'208";a="104898939"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Sep 2016 02:15:26 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 7 Sep 2016 02:15:25 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203%14]) with mapi id 15.00.1178.000; Wed, 7 Sep 2016 02:15:25 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: David Benjamin <davidben@chromium.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] CertficateRequest extension encoding
Thread-Index: AQHSBpsNFwO5ZBS5nEKu1fo1EPB7uqBo0NeAgAAAfICAAdZRgIAANz2AgAGl2N8=
Date: Tue, 06 Sep 2016 14:15:25 +0000
Message-ID: <1473171296219.4329@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>
In-Reply-To: <CAF8qwaDj5fP_zgFruu-Q+3+Hv-=6fkJbY_k4+b9-9PcHSidqfg@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/o5UyDwr4IbiFvPjwbpmFeYTJBrE>
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 14:15:33 -0000

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.

Peter.

v2.23.0 | Report a Bug | By Email