Create `TLS` cert arbitraries for testing

[tegefaulkes]

Specification

We want the ability to generate the TLS cert chain and private key PEMs for testing. We should also create fast-check arbitraries for this.

We need to replicate the KeyPair generation, x509 certificate creation and PEM format from the Polykey methods. Since these will be used for testing, the types can be striped down to primitives and any extra information can be as placeholder as possible. Refer to the keys domain in Polykey for how these are created.

Additional context

• Related Enable TLS Configuration with in-memory PEM strings #2
• Does boringssl support Ed25519 certificates? cloudflare/boring#113
• How to get Ed25519 x509 certificates working with quiche? cloudflare/quiche#1482

Tasks

1. Create simplified method for generating key pairs.
2. Create simplified method for generating x509 certificates
3. Create simplified method for generating cert chain and private key PEM formats.

[CMCDragonkai]

Important things I've already explained.

1. Enable TLS Configuration with in-memory PEM strings #2 (comment)
2. Enable TLS Configuration with in-memory PEM strings #2 (comment)
3. Enable TLS Configuration with in-memory PEM strings #2 (comment)
4. Enable TLS Configuration with in-memory PEM strings #2 (comment) maybe you need the webcrypto polyfill.

[CMCDragonkai]

It is critical to test a ed25519 signed cert chain as this is what is being used in PK.

[tegefaulkes]

Most of this is done now. I've lifted a bunch of functions from Polykey and stripped them down a little. Mostly removing the polykey extensions since they're not really used here.

The QUICClient tests are using fast-check to generate the TLS config now. but they're failing since the public keys are not properly derived.

The last step is to derive the public key from the private key. In Polykey it's using sodium-native to do this but we want to avoid using that here. One lead is to use the noble-ed25519 implementation to derive the key.

[tegefaulkes]

I'm looking into using the noble-ed25519 to derive the key. On the top level it's doing some simple stuff. but one stage relies heavily on the Point class which makes up most of the code. if I lift just the parts I need then I'm pretty much taking the whole thing.

So i may as well just import it. but attempting to import it results in an error. The noble-ed25519 module only supports ESM importing which we do not support?.

[tegefaulkes]

This is done now. Deriving the public key is done using sodium-native the same way as Polykey. sodium-native has been added as a dev dependency.

[CMCDragonkai]

Great! Did you test cert chains too?

[tegefaulkes]

Yeah, tested with random length cert chains with a min of 1 cert. The connections still timeout for me but I think that's a separate issue. I've confirmed that the config is generated without error.

[tegefaulkes]

Since there is a problem with the generated certs I'm going to re-open this issue.

What I know so far is that

1. The QUICClient tests are passing when loading the cert from a file. This file is a simple cert with a RSA key.
2. The tests are passing when loading the certs from memory using the same certs as 1. So we can conclude that the config changes are working.
3. The tests fail with timeout when using the test-generated certs. These certs are a stripped down version of the Polykey certs.

So the problem could be

1. The certs are generated badly
2. Some of the stripped out information may be important.
3. The generated certs are using an ED25519 key.

To verify the problem we can take two approaches to start.

1. Verify the generated cert using the step program to inspect the contents of the certs.
2. Generate a cert using a ED25519 (OPK) key and test using that.

Beyond that I need to narrow down why the tests are timing out and try to extract more useful errors in this case.