Re: [TLS] CertficateRequest extension encoding

David Benjamin <> Sat, 24 September 2016 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4208012BF09 for <>; Fri, 23 Sep 2016 17:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.015
X-Spam-Status: No, score=-5.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, 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 ReKiLfBi_t_J for <>; Fri, 23 Sep 2016 17:56:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53ED112BF03 for <>; Fri, 23 Sep 2016 17:56:48 -0700 (PDT)
Received: by with SMTP id m186so134256302ioa.2 for <>; Fri, 23 Sep 2016 17:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ewcjbKY9hQFJM28lHuWBGMh1U1Hbeg12lWsUP+XoqbQ=; b=F718o1N17CYcMsypsPKCVSEjM8H+koMCOweh7auhgccc71PBH2q9Wi3oFIdU1U9jK5 MUQ6v02WHlEr6r1oyJjXeV4ORWCa3Aigp1otAFqfjYp+1nssOxJpYHcbjD3F2DxH54UW PxcoSgPyzaFW/1vwhNZMMRmAHlNDzlmDgsbxk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ewcjbKY9hQFJM28lHuWBGMh1U1Hbeg12lWsUP+XoqbQ=; b=FRRTj0ODi1iDp01esNasih1SDSPyRJA0YW6gnlobV2ErodcxyvHv2Dcl7Xd+Bn7A3f L71fzV4Ls7X3iConOhybPcq+62uzVu1A7wMdbuzb/4q9ExcbCqr8i/5CtaYcto0eicH6 AEGqL8Me4BpCqmlUzNeYyby19T3r1HFEEWZSWBGXtgL0R3UG+1Jp9HmJV8dnpONIphKr Lrr0svF/VVmanCHzgq1Wkw0H7m9JJjimKibPzUTs19PH65plaE5cRDxGIRDNf71yMsBz ccWgvbvAIpOrbFNnr9WSSgXbNzzxNgn3o49Eu6YTL6nKRmOlcMBy2JDmb5FUSkSMoHt5 VagQ==
X-Gm-Message-State: AE9vXwN+UDoxnrnrTYWAK46q5QccFvha67vk8HEfqZrvjLXaaWyx2QbvBzagD/yCYu0EgjAfROE86S/aN99hgKmb
X-Received: by with SMTP id s3mr11635066ios.115.1474678607502; Fri, 23 Sep 2016 17:56:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sat, 24 Sep 2016 00:56:36 +0000
Message-ID: <>
To: Nick Sullivan <>, Andrei Popov <>, Anders Rundgren <>, Peter Gutmann <>, Ilari Liusvaara <>, "" <>
Content-Type: multipart/alternative; boundary="001a113986a08f3b99053d365e82"
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: Sat, 24 Sep 2016 00:56:51 -0000

(1) seems reasonable. I don't have strong views there. I even jokingly
suggested it in the PR description.

I do not like (2). This requires implementations stash a copy of the
signature algorithms without known a priori whether it will be used or not.
And it means when receiving a CertificateRequest, you have to go check that
the extension was provided at all. I think that should stay bound to the
CertificateRequest and as a required field.

On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan <>


If we're changing this structure of CertificateRequest, I have two

1) Move DistinguishedName out of the structure and define it as a TLS-style
extension. It's not a required field.
2) Remove SignatureScheme from structure, and instead change the behavior
of the the "signature_algorithms" extension to include all server-supported
SignatureSchemes in the ServerHello in descending order of preference.

This will result in a much more compact message structure that can easily
be re-purposed for post-handshake server auth and other optional extensions
to TLS 1.3:

     struct {
         opaque certificate_request_context<1..2^8-1>;
         CertificateRequestExtension certificate_extensions<0..2^16-1>;
     } CertificateRequest;


On Thu, Sep 22, 2016 at 6:26 PM David Benjamin <>

On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <>

> 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?

Apologies for the delay. Been a busy few weeks. This is roughly what I was

What do you think?

Again, I don't actually care about this, so if you and others who would use
this mechanism prefer it as it is, I have no qualms. This is a "pull
suggestion", not a "pull request". :-)




-----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
Existing selection methods suffice (there's usually none on the client

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

TLS mailing list