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

2023-04-18 Thread Viktor Dukhovni
On Tue, Apr 18, 2023 at 09:06:40PM -0300, Soni L. wrote: > That seems particularly useful for federated networks (XMPP, etc). Why > not call these server-to-server certs? That's basically it. At least in OpenSSL, when a EKU extension is present in the client certificate, it must allow client a

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

2023-04-18 Thread kha.thach
AM To: Soni L. Cc: tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names Not necessarily. One could use client certificates to ensure that only authorized clients (e.g. a laptop with the client certificate in its key store) can access some resource. On Tue, Apr 18, 2023

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

2023-04-18 Thread Rushil Mehra
Not necessarily. One could use client certificates to ensure that only authorized clients (e.g. a laptop with the client certificate in its key store) can access some resource. On Tue, Apr 18, 2023 at 5:07 PM Soni L. wrote: > So like a "client" cert is just a way to say "yes I'm really > example

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

2023-04-18 Thread Soni L.
So like a "client" cert is just a way to say "yes I'm really example.org" yeah? That seems particularly useful for federated networks (XMPP, etc). Why not call these server-to-server certs? On 4/18/23 20:45, Peter Gutmann wrote: Richard Barnes writes: >Let's Encrypt issues roughly 3 millio

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

2023-04-18 Thread Peter Gutmann
Richard Barnes writes: >Let's Encrypt issues roughly 3 million publicly trusted certificates per day >that contain the client authentication EKU But they just set that by default for every cert they issue so it's pretty much meaningless. There are public CAs that set keyAgreement for RSA certs,

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

2023-04-18 Thread Richard Barnes
On Mon, Apr 17, 2023 at 11:41 AM Robert Relyea wrote: > 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). > Let's Encrypt issues roughly 3 million publicly trusted certificates per day that contain the client auth

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

2023-04-17 Thread Robert Relyea
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,

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

2023-04-12 Thread Martin Thomson
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 TL

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

2023-04-12 Thread Andrei Popov
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: tls@ietf.org Subject: [EXTERNAL]