Generate DC test vectors and add other signature schemes

[claucece]

Open for comments ;)

cc./ @cjpatton @chris-wood @xvzcf

[xvzcf]

To me, it seems like -make-dcvectors and -make-dc are the same thing. Also, instead of a -dc-algo argument, we could have an -alg argument that is passed to make-dc, make-root, etc. I say alg and not sig-alg because we might potentially wrap post-quantum KEMs in DCs.

[cjpatton]

To me, it seems like -make-dcvectors and -make-dc are the same thing. Also, instead of a -dc-algo argument, we could have an -alg argument that is passed to make-dc, make-root, etc. I say alg and not sig-alg because we might potentially wrap post-quantum KEMs in DCs.

I agree .... the new option is much more general. Though I would just stick with "-alg" or "-dc-algo" and not differentiate between KEM/signatures at this stage.

[claucece]

To me, it seems like -make-dcvectors and -make-dc are the same thing. Also, instead of a -dc-algo argument, we could have an -alg argument that is passed to make-dc, make-root, etc. I say alg and not sig-alg because we might potentially wrap post-quantum KEMs in DCs.

I like that of the -alg argument. Around the -make-dc one: I wanted to separate between the vectors and the dc used to run the test. But it could also be that the all of them are generated and the test just chooses one.

[xvzcf]

I like that of the -alg argument. Around the -make-dc one: I wanted to separate between the vectors and the dc used to run the test. But it could also be that the all of them are generated and the test just chooses one.

Yeah, I was thinking the latter. For each testcase, the CI runner will dynamically generate the artifacts, run a client-server interaction and then clean up by deleting the artifacts. If (for example) signature algorithms for the root, intermediate cert, and DC are chosen randomly for each testcase run, this might get us decent coverage of the many possible combinations without too much additional complexity.

[claucece]

@xvzcf @cjpatton check how it is working now. It is not so simple to choose randomly a cert, as it has to be a valid cert for the dc that are generated upon them. For the moment, it is randomly choosing a DC.

[claucece]

This is done now. I added some todos regarding:

• Generating the randomness for the algorithms to be chosen should be done by golang itself as discussed with @xvzcf
• Generating certificates with all other tls 1.3 supported algorithms need to be supported.

I can send that as part of other PRs.

Let me know what you think @xvzcf

[xvzcf]

This should be fine for now, but I'm guessing once we handle RSA we should probably have a separate struct for that.

[claucece]

It could also be that we have a bool for each case: isRSA, is ed25519 and curve param for eddsa.

[xvzcf]

As discussed, the TODOs can be addressed once I break out the common code into an internal library.