test different keytypes/schemes

[jku]

We should use a default keytype in most tests (currently RSA, ecdsa maybe makes sense after #155). In addition we should have specific tests for support of various other keytypes. Specification does not really require support for any specific keys but these are mentioned in spec:

keytype	scheme
rsa	rsassa-pss-sha256
ecdsa	ecdsa-sha2-nistp256
ed25519	ed25519

We should definitely test these.

Additionally potential testable keys might include	keytype	scheme	note
ecdsa	ecdsa-sha2-nistp384
ecdsa	ecdsa-sha2-nistp521
ecdsa-sha2-nistp256	ecdsa-sha2-nistp256	legacy keytype name still supported by some implementations
ecdsa-sha2-nistp384	ecdsa-sha2-nistp384	legacy keytype name still supported by some implementations
ecdsa-sha2-nistp521	ecdsa-sha2-nistp521	legacy keytype name still supported by some implementations
rsa	rsassa-pss-sha224
rsa	rsassa-pss-sha384
rsa	rsassa-pss-sha512
rsa	rsa-pkcs1v15-sha224
rsa	rsa-pkcs1v15-sha256
rsa	rsa-pkcs1v15-sha384
rsa	rsa-pkcs1v15-sha512

[jku]

So I guess we should write a single parametrized test (or one test for the keys mentioned in specification, another for additional keys) that

• builds a repository using given keytype/scheme for at least one signature
• tests client refresh is ok
• creates a new version of the metadata, modifies signature so it's incorrect
• tests that client refresh fails

We could add more pre-generated keys to repository_simulator.py (like RSA_PKCS_SIGNERS) so at least the keys are ready in case we decide to use them in more than one test.

[jku]

maybe an additional test: use an incorrect but supported key like ecdsa-sha2-nistp256 but have the metadata claim that it's ecdsa-sha2-nistp521. I think a client should fail this even though it could parse the public key and correctly handle it: as it looks like the repository is trying to mislead a human reader.

[jku]

I've got an initial test in #167

[jku]

Status:

• test_keytype_and_scheme now tests the three keytypes named in the spec
• we really should test other keytypes as well

The only obstacles are:

• need to use cryptography: there is an example in https://github.com/secure-systems-lab/securesystemslib/blob/main/docs/CRYPTO_SIGNER.md see Generating a new private key with cryptography
• not all clients will support this: I think --expected-failures should work fine but we may want to make it more ergonomic before adding a dozen tests that someone will need to set to xfail (see https://github.com/theupdateframework/tuf-conformance/issues/33#issuecomment-2310051042 for a possible solution)