Mechanisms to offload/move the static ECDH calculations?

Thank you for WireGuard, it is an amazing tool.

These last months, I have been pondering how to integrate WireGuard with
the classical hardening of trapping the private key material in a device
and rendering it "unextractable" (modulo classical attacks on TPM2,
security keys, you name it.)

As I understand it, WireGuard exploits the private key to do an ECDH and
immediately continue the protocol without the static private key until a
reconnection.

I wonder if the *kernel* WireGuard implementation could offer means to
offload this specific ECDH calculation to userspace, what would be the
conditions or the reasons not to pursue such a thing. I am aware that
the userspace implementations can do that, but I find them less
interesting than the kernel implementation (proper forward secrecy,
formally verified cryptography usage, etc.).

If such a capability was offered via a Netlink message or anything,
userspace programs could prepare the ECDH result by calling into
userspace APIs to "secure devices", e.g. PKCS#11 for TPM2/security keys
or more specialized APIs. I considered the possibility to do PKCS#11
inside the kernel and I guess this is a non-starter due to the
complexity of this ecosystem and the danger it represents.

I realize that offloading the ECDH calculation to the userspace might be
dangerous and not constitute anymore what WireGuard(R) stands for, I am
interested to hear more about the vision around this.

Additionally, I understand that another way to go about this problem is
simply to forego the need to store the private key materiel in a secure
device by having it rotate regularly enough, which is the path that has
been taken by various software that works on the top of WireGuard and
provide some control plane distributing keys and so on. Unfortunately,
this requires *additional* infrastructure and this creates more SPOF
risks, in the context of building disaster recovery infrastructure, it
is often desireable to have break-the-glass private keys that can log in
even if the SSO/OIDC/control plane thing is down. It would be awesome if
that key could be stored in a "secure device" with the adequate policy
controls. Even more awesome: it would exist in native kernel WireGuard
and userspace could provide the hooks to make it this available out of
the box.

So this is really my question:

Is there any principled reason the in-kernel WireGuard implementation
must compute the static ECDH in-kernel?
  
If not, would the WireGuard developers accept an API that lets userspace
supply the precomputed ECDH outputs for the handshake
initiation/response?

If the answer is yes, I think the next questions will revolve around on
the design, what are the guarantees that must be uphold, consequences
about the ratelimit engine, etc.

Kind regards,
-- 
Ryan Lahfa