Re: [TLS] CertficateRequest extension encoding

Andrei Popov <> Tue, 06 September 2016 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AACE12B546 for <>; Tue, 6 Sep 2016 10:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rS9-qbSRJTWB for <>; Tue, 6 Sep 2016 10:03:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAAFE12B475 for <>; Tue, 6 Sep 2016 10:03:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R6pfwtuZLA/KAdZkE7X/Zisf35XttpwgPOTGZ3RBwsI=; b=GufIPa8/VNiyqOf2O6cd09qiSkhsVPKzguv95PyDAXcq1iblvJP8t/drlcpndcyOmxLMUglECpQKuq80lyKEjxHCrOFmgCQ0jeHeI6fBlp9h+dh+rS14vjt8a8u7hgXDixxeNzwVVzIidAbdRkKQoLll5KbpqE0YTTTG7IUSP4U=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 6 Sep 2016 17:03:06 +0000
Received: from ([]) by ([]) with mapi id 15.01.0599.016; Tue, 6 Sep 2016 17:03:06 +0000
From: Andrei Popov <>
To: Anders Rundgren <>, Peter Gutmann <>, David Benjamin <>, Ilari Liusvaara <>, "" <>
Thread-Topic: [TLS] CertficateRequest extension encoding
Thread-Index: AQHSBpsXZcombga0NEGFs2xYmfILPaBpmgGAgAAAfICAAc2xcIAAP92AgADc94CAABaMgIAAEfdw
Date: Tue, 06 Sep 2016 17:03:05 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:b::1d2]
x-ms-office365-filtering-correlation-id: 6c7ed74a-9716-4821-bf7f-08d3d677abee
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:FZQsU7DGq+bHFNlxLEwgr3ZUL8Y7OXJaxYls2DNxolpjRZnmuPCuPSCQvGLRQPXjZ3V/XUHxjdceK0Hbajs9BRDhKWZ7VSO+gsGOMcdht9w8B0gahNIIsLG7FfEDxee9HGOP055hzWcOO/f1H+9KlSwEvGXZtdB2OF52lXp1nBiI8OMECx38QV6OdaJl5xtKKCLB7FuAzgbaxP5DM4dnPlqV/76fr8LP71vIbSw7dU3V78AoRVjZOao5SgGJz6YSK/2NJNV+w7LZWqalFNKcgRy2gl0PPI6dqiC3CieHCPXOEhMxYiZn+SglDaqnqZV9nFE5NOyazIpCx5LrxWESRA==; 5:VCwSSnEmvsgJDK/ZJ1J+fDgnxw77zcQm/AU4r8Ci1Bl3OX4BZB36SMA72S/mtD+X6442Mod0p6SaqTjZc/aYcZcTLdi7T+f4Uqt98vZ+7cO7KGbg1ZWdZKg8yWEqwqYS1WlNUvD6jeT38k+P+Tckjg==; 24:3qKkxSO7wGr07RAVA1UpZO0Ok3hlSqUKHZzZ6nbAOcXqM/w9gn/kegrOweopzVgqs7VWQOCU2/+EwV1TeLbZVMC/nanwG9GdxkH27ixLAG0=; 7:fdAxUtnmVgIKyik4kfv8JcR1PUsnbian7eZL2fTYK+aLvyD25UhPBqGKgpbdT9aYlgqTn5uzl3jx5y9+WnMfTMUGLS8BGwj59iDgibZzLEqYKhR1a35JTzGwKKOjBte4WwN7oWiWxJlq2lWPYM4/yp/4G/czmoBJKCxiuHvgJrOFAkBfKHA5Hcqt2Y7HEvGhtA5UsQxzwJnjcpUTARe5iW2eAjJtq9/Mkemq560oncHwymD4cTKIXnGL6qg7q8A5
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841;
x-forefront-prvs: 0057EE387C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377424004)(377454003)(13464003)(189002)(24454002)(5660300001)(77096005)(122556002)(54356999)(76176999)(86612001)(50986999)(93886004)(11100500001)(15975445007)(87936001)(19580405001)(19580395003)(76576001)(6116002)(99286002)(86362001)(106356001)(7846002)(105586002)(106116001)(7736002)(8676002)(305945005)(81166006)(92566002)(81156014)(7696003)(97736004)(8936002)(2950100001)(5002640100001)(3660700001)(2906002)(189998001)(3280700002)(33656002)(2501003)(5001770100001)(5005710100001)(9686002)(10090500001)(74316002)(8990500004)(586003)(10290500002)(68736007)(10400500002)(107886002)(2900100001)(561944003)(101416001)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2016 17:03:05.9491 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841
Archived-At: <>
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 17:04:00 -0000

> 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...
This is actually a pretty good description of a number of deployments our customers have. On the other hand, a lot of Web clients can do without OID-based client cert filtering, so certificate_extensions support is optional (and if this is not clear, we should fix the language).

> Client-certificates are *extensively* used for secure box-to-box communication.
Correct, and this adds to the smorgasborg of client certs.

> But it's OID-specific how the matching works, isn't it?
Correct, and initially we define matching for KU and EKU. These are the OIDs I've got the most customer requests for. I expect that we will want to define matching rules for other OIDs over time, in separate specs. This new proposal allows multiple sets of matching rules for each OID, which certainly increases flexibility.

David, do you care enough to write your proposal down as a PR, so that we can discuss the specifics?



-----Original Message-----
From: Anders Rundgren [] 
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann <>; David Benjamin <>; Andrei Popov <>; Ilari Liusvaara <>;
Subject: Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
> 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.

May I add some nuances here?

Client-certificates are *extensively* used for secure box-to-box communication.
Existing selection methods suffice (there's usually none on the client side).

Client-certificates for user authentication on the Web through HTTPS is a small and diminishing activity. The decision by the browser vendors dropping support for on-line enrollment is likely to further limit this use case which make improvements in selection/filtering pretty uninteresting.

Client-certificates for user authentication on the Web through through proprietary ("FIDO like") application level protocols is fairly big.  Half of the Swedish population use such a scheme for e-government and bank access.  It uses an ugly (and non-secure) OOB-method to make it "Web compatible".  This use-case is (of course) not of an issue for the TLS WG but may be of some interest for people currently using client certificates for Web authentication.


> Peter.
> _______________________________________________
> TLS mailing list