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 <[email protected]> *On Behalf Of * David Benjamin
*Sent:* Wednesday, April 12, 2023 2:16 PM
*To:* [email protected]
*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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
