On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara
wrote:
> On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> > On the subject of clarification, the update also needs to explain why
> PSK is
> > split across two separate extensions, psk_key_exchange_modes and
> > pre_shared_key,
On Wed, 5 Apr 2023 at 06:32, Stephen Farrell wrote:
>
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it
Is this generally used? Would things go badly if we stopped sending them?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich writes:
>Is this generally used? Would things go badly if we stopped sending them?
Just as a data point, in the SCADA world it seems to be universally ignored.
I've seen everything from servers that send a list containing every CA in
existence, so much data in that one field that it
On Wed, Apr 12, 2023 at 08:41:31PM +, 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
> I take you mean sending CA names as part of a certificate request.
Yes, that's what I meant.
>It looks perhaps like CA name lists are "more optional" in TLS 1.3 than
they were in TLS 1.2
That's kind of what spurred my question.
___
TLS mailing
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
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]
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.
Ben Smyth writes:
>Because pre_shared_key appears in ClientHello and ServerHello, whilst
>psk_key_exchange_modes only appears in the former?
That's a circular argument, pre_shared_key already has two different forms
that depend on whether it's the ClientHello or ServerHello it so this is
saying
On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> On the subject of clarification, the update also needs to explain why PSK is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key, with complex and awkward reconciliation rules between then,
> and why
11 matches
Mail list logo
