Re: [TLS] [EXTERNAL] Re: Servers sending CA names

Martin Thomson <> Thu, 13 April 2023 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01109C15C288 for <>; Wed, 12 Apr 2023 18:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b="q66a5NCK"; dkim=pass (2048-bit key) header.b="Lt7GUZa3"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z5G9dmTMbiUa for <>; Wed, 12 Apr 2023 18:04:09 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id E9BB6C1522CD for <>; Wed, 12 Apr 2023 18:04:09 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 3B15F3200957 for <>; Wed, 12 Apr 2023 21:04:07 -0400 (EDT)
Received: from imap42 ([]) by compute6.internal (MEProxy); Wed, 12 Apr 2023 21:04:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1681347846; x=1681434246; bh=7hOCP5dNxZEq+yGFPN10JWx6mYmgl0H4CaP OhbNDQR4=; b=q66a5NCKLFthyIfQ0kZpS2WQoG5eM0qV0ShkgPelGlvTX5RkytY zZmAv0yKHHYoQn/nno3WUbhYhz31RQAKZ4zF7HxtlzWYAOrG4VOBTEr/iZiWkiV9 P2PC603eaxZQ110qTpQb7w+jyZbZbil0biO6ThfOQei+BuzKMT4bNQFMHCNNeYRD dUqEfNkHIFGB5NnGEUwJQYI092pLaLA0kRHUMqiH6ZN8FS20+nfiWNEgucflCjD2 57w7RyUwsTshqq0Ycu6GoeSg1sEf7uVwIkV8t0IzyPoxT/F0aKxuEyGuRkS0NOjA /yUCP/ljV/c2LDuDRyBDDdVG3jxOHtGrQXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1681347846; x= 1681434246; bh=7hOCP5dNxZEq+yGFPN10JWx6mYmgl0H4CaPOhbNDQR4=; b=L t7GUZa3JIa3rdsVh9R8WHHO2p5Rf0rVQhQmRjy0jn54GBJgU5La1hAqrPZz1Ssol yzbLeiIIK32tQK5/xKblHt2fYWd1AfBCG7Bi9WcC116/n8Tj55XFEfNnK2wmhmqY 4tyFVJ41lA3O0ldmIKcI0xxpu8/tVkFhJYUTHDQyeV8shVMhxJ9NZ+1urD2PyFs1 y0OQodN1DN4Y7i+ZpSPsO4mQN1Q8Q3KsA52noPp8hXQUZ8GQVMtMDmWECkxxxaQp QTF01YtQbCAQ8TOfs+o2TREW+FsdjG9oVBKnF8G0Fvz3iE98o1kW/IL/kOjogKDJ HvSQjE9flho/mG1ogkhpw==
X-ME-Sender: <xms:BlU3ZAGKjCLQW8cvyiYiiEcZgEoNIT-4s0hZLxYnzO5hWYLW-hKJyg> <xme:BlU3ZJXEtVhKjEyIUByymiIKV3HDCJf9ief5HiVCr1TdOcjXmTNgJGeR3Ht4jRvY3 f6E1mhlSL2tuZiuXNw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekjedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:BlU3ZKLpvnouhUP89yZ4lE9d2W8zg8882o2bkYHU9OVCeNJWoVZ6xw> <xmx:BlU3ZCFybOu8RRCKwQg3JBEiS-zpM3Vu48Fw3lHYg-qfYhb9chhN4g> <xmx:BlU3ZGUCZrwLPzy3GdDAqFCCNv3Y2EJgkcbhdA7DR54JL22y_-pilA> <xmx:BlU3ZOjTSdvYy_IYFJrNwrMhwaRD565CCzBADLtOEq2upqrwSEJiIQ>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E3EEBC0078; Wed, 12 Apr 2023 21:04:06 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 13 Apr 2023 11:03:47 +1000
From: Martin Thomson <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names
X-Mailman-Version: 2.1.39
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: Thu, 13 Apr 2023 01:04:15 -0000

I think that is also true for NSS, though my experience of this is not thorough.  As David notes, client certificates are something of a mess once you step outside a context where the client already knows what it should be sending.

On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote:
> Windows TLS stack uses them (when available) for certificate selection. 
> Schannel-based TLS servers don’t send CA names by default, but can be 
> configured to do so.
> Cheers,
> Andrei
> *From:* TLS <> *On Behalf Of * David Benjamin
> *Sent:* Wednesday, April 12, 2023 2:16 PM
> *To:*
> *Subject:* [EXTERNAL] Re: [TLS] Servers sending CA names
> Chrome also uses this to filter the set of client certificates when 
> asking the user to pick one. We also sometimes use this to figure out 
> what intermediates to send, in cases where the server does not already 
> have all its intermediates available. (Though this is not very reliable 
> and OS-dependent. Client certificate deployments are a bit of a mess.)
> Omitting it may be fine in contexts where you expect clients to only 
> have one possible certificate chain and that they have a priori 
> knowledge to only send that one. That can make sense in 
> machine-to-machine communication, and makes less sense when the client 
> is a human that needs to make decisions about identities to use.
> I agree with Viktor that this isn't any more optional in TLS 1.2 than 
> TLS 1.3. Optional and non-empty if present vs. mandatory but may be 
> empty express the same set of states. It's just an encoding difference, 
> motivated by extensibility and client/server symmetry, not changing 
> client certificate expectations.
> On Wed, Apr 12, 2023 at 4:59 PM Viktor Dukhovni <> wrote:
>> On Wed, Apr 12, 2023 at 08:41:31PM +0000, Salz, Rich wrote:
>> > Is this generally used?  Would things go badly if we stopped sending them?
>> I take you mean sending CA names as part of a certificate request.
>> Yes, many servers send a non-empty list of CA names as part of
>> certificate request, and some clients (notably some Java-based clients)
>> fail to complete the handshake if the request does not list an issuer
>> associated with any of the client's available certificates.
>> So servers historically have been able to get away with an empty list,
>> hoping that the client will then send the only/default certificate it
>> typically has on hand (or not send any, but still continue the
>> handshake).
>> It looks perhaps like CA name lists are "more optional" in TLS 1.3 than
>> they were in TLS 1.2, but this impression may be just an artefact of the
>> separation of the CA names to a separate extension, rather than an
>> actual change of expected client behaviour.
>> -- 
>>     Viktor.
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list