Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.

> but does the kernel then also do certificate validation for you

No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.

The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?"

The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.

It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.

Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself.

Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways".

Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.

The kernel already does TLS, but the handshake happens in user-space.

It will not.