Ilari Liusvaara writes:
>You mean overflow the maximum field size (64kB)?
No, just the 16kB message size, so you get what should be a ~100-byte cert
request that's 20-30kB long. The code assumed - and I know this is crazy talk
here - that a 100-byte message would fit easily into a 16kB I/O
On Thu, Apr 13, 2023 at 02:35:50AM +, Peter Gutmann wrote:
> 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
One purpose additional to the already mentioned selection of the "right"
client certificate may be to truncate the sent client certificate path
at such a CA certificate, though that certificate is already available
at the server.
If x509 is used at all for IoT, such a truncation may reduce the
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
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.
> 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
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
