Re: [TLS] Servers sending CA names

David Benjamin <> Wed, 12 April 2023 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C68EC1524DC for <>; Wed, 12 Apr 2023 14:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.245
X-Spam-Status: No, score=-9.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1i2NiFJtX1hb for <>; Wed, 12 Apr 2023 14:16:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id DD88FC1522D9 for <>; Wed, 12 Apr 2023 14:16:02 -0700 (PDT)
Received: by with SMTP id 00721157ae682-54f6a796bd0so129504567b3.12 for <>; Wed, 12 Apr 2023 14:16:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1681334161; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=iu9m5WcQ29sNwHMr+oGt1wG7SpqZTFKqUCwmcdQmVOA=; b=U/5SmHAkWqmhivSJ7Aj41CTcBZCXouEfwmUbt/3hMLu7r3MMmJxgsB0oTRrKFatMR5 D7O+36AV7liD0DvN30TU8RE5hjD3JTX7oqZNfnmUBlppEmi0/bBaO+Jjz9ROAZU1kfYV 9tjiKxsiBx3DMeWzctG1v7D2TlGB/Y3+7SagE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1681334161; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iu9m5WcQ29sNwHMr+oGt1wG7SpqZTFKqUCwmcdQmVOA=; b=WFdwu8fT70pV7VgYHijeGTqbPB3rJ7vamAcm/BUpFHzT9Xl7hZ5eyGdqY7jkBufHdn 5GEbTidCfm8UEfYXCvF/jR870D+kR6sIagBh0M+cqzVVYwEmn3pQcXK6KZizehSc8VTU x1RLuKi13D6aGqjNsMvXTR0gc6lev6sm84P7tqctqEfCxS7B0cft6TubtZq7YprPB15H AawxPut2vt7HNF+lbrHGRBLBWxY5fcrQ6SZAhIcY9uIp8j822DnvLB3X20CL7xEPm007 YRwYQ8Kp28ZinA2X2zc1QTqNvWNYF6C2p5uxl86Lne7O8gMAsdH1WVb/qmhQbw5Emn58 BSyA==
X-Gm-Message-State: AAQBX9dXYtLUijnZiokPO2Vi4ZTCdJmJjYQ+0nlmhIeruccUXW1YUkDj XCfRz0JqIC/P0Wbvo0AHM1RODxCVMpOA4kx02HPxujiFGC7XW8TV5A==
X-Google-Smtp-Source: AKy350biZBxO1TFHNmx5oNMvgLbjULUKHZO3TJT4CPaeyE1SNMeR08zaF/sQGET9HibR6C1iaAwYGBjmkMB2M7C+8/w=
X-Received: by 2002:a81:c608:0:b0:54f:93c0:4ba8 with SMTP id l8-20020a81c608000000b0054f93c04ba8mr2080440ywi.2.1681334161292; Wed, 12 Apr 2023 14:16:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 12 Apr 2023 17:15:44 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000006f4d9905f92a1ded"
Archived-At: <>
Subject: Re: [TLS] 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: Wed, 12 Apr 2023 21:16:06 -0000

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

> 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