WebTransport connectivity with non-deterministic certs to support FIPS

For WebTransport currently the go-libp2p implementation generates deterministic certificates

https://github.com/libp2p/go-libp2p/blob/31c8c833080f819fdd52953092f53053443a9dc7/p2p/transport/webtransport/crypto.go#L74

Whilst both HKDF and ECDSA are separately FIPS approved and have FIPS certified implementations, the FIPS approved ECDSA key generation function must use certified entropy source, and thus generating random keys/certs.

See this block here https://github.com/golang/go/blob/da9c5b142c855496222f0ab167c3f1d9e98403c4/src/crypto/ecdsa/ecdsa.go#L165 in golang toolchain in fips mode.

Reading the libp2p specs it is not clear to me if deterministic certificates are required; or if it is just a chosen implementation detail in go-libp2p.

The change to use deterministic certificates was done in https://github.com/libp2p/go-libp2p/commit/a0432e70afd1a5b0f8f63ecc46406132324e7bee

Is it possible to optionally support non-deterministic certificates, like it was done prior to the above commit, for example with a build-tag ?

Because for FIPS case allowing to generate predictable keys sounds like unapproved usage which is difficult to bypass, and guard against misuse (ie. whilst it might be suitable for libp2p connection, it likely is not a good idea for the general purpose generic API of generating ECDSA keys, and changing standard library module would affect all users in a given project compilation).

Start by reading the referenced libp2p specs and p2p/transport/webtransport/crypto.go, then compare the prior deterministic-certificate change with Go's crypto/ecdsa.go FIPS behavior. Determine whether the specs require deterministic certificates and define the acceptable optional mechanism for non-deterministic certificates; done means the requirement and implementation direction are unambiguous.