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

Robert Relyea <rrelyea@redhat.com> Mon, 17 April 2023 15:41 UTC

Return-Path: <rrelyea@redhat.com>
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 E7E22C151B17 for <tls@ietfa.amsl.com>; Mon, 17 Apr 2023 08:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGnfRHW4PFSB for <tls@ietfa.amsl.com>; Mon, 17 Apr 2023 08:41:11 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 55FF6C14CEFF for <tls@ietf.org>; Mon, 17 Apr 2023 08:41:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681746070; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y0mAsUHZYhOo3RvSoQoWDQW/jDZ7zauv9i6qPV4VwmE=; b=fvm9qpJjqO48KlO3QXoD578FWp18lXSslPWtatVCxMKOhtLSIFWIEVSLdf5GgeEdneb2qj ImQAMp/BlU3ixlUwQs3bNiCuffps8Mj4tOhUKQ2zFJPGBwCQjbC82lkU/J31Lna7pJ43JU XWZFWB8ruEMzJTNX+nqOmHxhkukNnYs=
Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-540-RDIN0kHCPA2HB25LEA92Fg-1; Mon, 17 Apr 2023 11:41:08 -0400
X-MC-Unique: RDIN0kHCPA2HB25LEA92Fg-1
Received: by mail-qk1-f198.google.com with SMTP id 194-20020a370acb000000b00746b7fae197so1207675qkk.12 for <tls@ietf.org>; Mon, 17 Apr 2023 08:41:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681746068; x=1684338068; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y0mAsUHZYhOo3RvSoQoWDQW/jDZ7zauv9i6qPV4VwmE=; b=ckZqxY+veiPveWo2sbatjbahJQms9lnHVNqKywNuH4trrjKnoKafjcINyhBMI9y2JQ MiQ+yfr0cJs1kKGdxcJo8cc4GyxWg41t2dS2LHBOGXriHM0JuHCUuXa3SDdTrLZT+x61 LBIbEmLUqj5iVSnEKkJAno5JeY1nWKYocsLd90a/IaoxoU8FyUKHUXb0XfJY6wTI/wTK xV4I1qO7507WNRWRkRkUVPH5exAV4wfBJbITblG8ILPSeu+vldj7qbYuih8+lOxX56zO xzj7PZcTA1//wVtnKjTi7iAEnU0945WuQz6xSmGQD+6iQl9dq3AhIjeQNpl99Y5ylZHv oAig==
X-Gm-Message-State: AAQBX9cNb2YoSU97TBsl6mHJGxYrX/L2gdM/6zpQp+0wzQw/KWyBmFgs PhySWYI9HNt9xCbtTVWgobuJmB9P+MdUbPGieXY8Dt3RXup+NBiCvadtbW85r2DFe3orM2B/Qp7 2Hv8H22htdg3L4z5cQf5uXh4pO0QZSoaga/KmaoLtgoXaWmPIsn7D7VcN68vurQ==
X-Received: by 2002:ac8:5902:0:b0:3b6:3a58:912d with SMTP id 2-20020ac85902000000b003b63a58912dmr20647104qty.0.1681746068074; Mon, 17 Apr 2023 08:41:08 -0700 (PDT)
X-Google-Smtp-Source: AKy350b/SXhKt6mbpKGpCOleevLDLUnpKWkKDudEfounp30sW0+vBET1SgMI3UwzGl4FYbPk7m4AfQ==
X-Received: by 2002:ac8:5902:0:b0:3b6:3a58:912d with SMTP id 2-20020ac85902000000b003b63a58912dmr20647066qty.0.1681746067640; Mon, 17 Apr 2023 08:41:07 -0700 (PDT)
Received: from [192.168.1.172] ([98.47.139.97]) by smtp.gmail.com with ESMTPSA id x25-20020ac87ed9000000b003ef2c959d1bsm929175qtj.67.2023.04.17.08.41.06 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Apr 2023 08:41:07 -0700 (PDT)
Message-ID: <e5970ece-973b-e758-03b5-0e6ea2dc0b1b@redhat.com>
Date: Mon, 17 Apr 2023 08:41:00 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
To: tls@ietf.org
References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com> <ZDcbv4g5-tjN-Mu-@straasha.imrryr.org> <CAF8qwaBaOq1_Ow_vtB=DGjjDkAx+N+CPMpfn1huP=DRsCiFtaA@mail.gmail.com> <BY5PR00MB06757280F69B9C6D55AD2B048C9BA@BY5PR00MB0675.namprd00.prod.outlook.com> <accacacd-2bd6-4c89-8221-0c32b1a25ae3@betaapp.fastmail.com>
From: Robert Relyea <rrelyea@redhat.com>
In-Reply-To: <accacacd-2bd6-4c89-8221-0c32b1a25ae3@betaapp.fastmail.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VS3szFB_bNiP0v0o3_MSyUXoY8U>
Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Apr 2023 15:41:14 -0000

On 4/12/23 6:03 PM, Martin Thomson wrote:
> 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 the server side, NSS sends the names of CA's marked in it's database 
for Client Auth (as opposed to server Auth). NSS has no default 
certificates set to Client Auth, with the presumption that client auth 
certs are different than email or server Auth because they are issued by 
a CA trusted by (and perhaps controlled by) the server.

I know of no public CA which issues SSL client auth certs (or what it 
would mean for a server to trust a public client auth cert).

bob

>
> 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 <tls-bounces@ietf.org> *On Behalf Of * David Benjamin
>> *Sent:* Wednesday, April 12, 2023 2:16 PM
>> *To:* tls@ietf.org
>> *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 <ietf-dane@dukhovni.org> 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.
>>>
>>>      https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
>>>      https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4
>>>
>>> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls