Determine a key reuse/output regeneration policy

[woodruffw]

At the moment, the test suite is entirely re-built whenever make limbo.json is run. This includes all keypairs and certificates, meaning that key IDs, serial numbers, etc. all change each time.

This has some pros and cons:

• Pro: Regenerating each time ensures that we don't accidentally introduce staleness or non-reproducibility to the test suite, e.g. a testcase that loses its corresponding Python definition.
• Pro: It's simple this way.
• Con: Consumers of the test suite can't assume stable serial numbers or key IDs as fixed identifiers in downstream testing, at least not without updating them whenever they update the suite. This may be a "pro" in disguise.
• Con: It makes the git history chunky.

CC @alex for opinions.

[woodruffw]

The new Builder APIs aren't cached anymore, which is making generation pretty slow (probably mostly in RSA keygen). We should probably either cache them again or rethink something more aggressive here (like storing the keys on disk.)

[woodruffw]

We switched to using ECDSA + P256 keys in #46, so this is now fast again. But it still isn't ideal that we rebuild the whole thing each time.

[cipherboy]

We switched to using ECDSA + P256 keys in https://github.com/C2SP/x509-limbo/pull/46, so this is now fast again. But it still isn't ideal that we rebuild the whole thing each time.

Unsolicited advice from some named Alex but not the tagged Alex :-D

You could use a KDF here, seeded with context about the test case & usage to make it deterministic but unique. This would give you unique keys/serials per test (which is a nice property) and let you explicitly switch to new keys if you want via rotating the source key... Each field could be different KDF context, rather than one long read to let you introduce new data without caring about the order it is requested in.

IIRC, ed25519 keys might be a little nicer than P-256 for KDF-based generation, but might limit compatibility in some scenarios (if ed25519 isn't supported, e.g., legacy FIPS modes before they were added here recently).

This is a little better than a deterministically seeded RNG in that you don't risk changing values if you need to read more data or reorder or add more tests (as this new random value would be a new KDF invocation with different context and thus wouldn't affect other calls by changing their global order).

[woodruffw]

Using a KDF is a good idea, thanks!

Unfortunately, we can't immediately switch over to Ed25519 for keys, at least not for a decent chunk of the suite (since Ed25519 isn't in the CABF BRs yet). But I'll look into attempting this with the NIST curves.

Worse case, we can always "cheese" it and keep a "bank" of keys around in the repository, with sufficient unique keys for all of our testcase path combinations.