Conformance suite feature parity

[tnytown]

Requires #326.

• [ ] Detached materials
• [ ] 0.3 bundles
• [X] Staging instance
• [X] Custom trust root

Current failing tests:

FAILED test/test_bundle.py::test_verify_v_0_3 - test.client.ClientFail: 
FAILED test/test_bundle.py::test_verify_dsse_bundle_with_trust_root - test.client.ClientFail: 
FAILED test/test_bundle.py::test_verify_rejects_invalid_set - test.client.ClientUnexpectedSuccess: 
FAILED test/test_bundle.py::test_verify_rejects_bad_checkpoint - test.client.ClientUnexpectedSuccess: 
FAILED test/test_bundle.py::test_verify_rejects_checkpoint_with_no_matching_key - test.client.ClientUnexpectedSuccess: 
FAILED test/test_certificate_verify.py::test_verify_with_trust_root - test.client.ClientFail: 
FAILED test/test_signature_verify.py::test_verify_empty[SignatureCertificateMaterials] - test.client.ClientFail: 
FAILED test/test_signature_verify.py::test_verify_mismatch[SignatureCertificateMaterials] - test.client.ClientFail: 
FAILED test/test_signature_verify.py::test_verify_sigcrt - test.client.ClientFail: 
FAILED test/test_simple.py::test_simple[SignatureCertificateMaterials] - test.client.ClientFail: 

[tnytown]

Getting the following error on staging when tough tries to fetch a root (5.root.json):

Invalid key ID 5416a7a35ef827abc651e200ac11f3d23e9db74ef890b1fedb69fb2a152ebac5: calculated c3479007e861445ce5dc109d9661ed77b35bbc0e3f161852c46114266fc2daa4

[jku]

Getting the following error on staging when tough tries to fetch a root (5.root.json):

Invalid key ID 5416a7a35ef827abc651e200ac11f3d23e9db74ef890b1fedb69fb2a152ebac5: calculated c3479007e861445ce5dc109d9661ed77b35bbc0e3f161852c46114266fc2daa4

This is https://github.com/theupdateframework/tuf-on-ci/issues/292 and arguably https://github.com/theupdateframework/specification/issues/305

Very annoying...

• I think this is a bug in tuf-on-ci (and so in root-signing-staging metadata) and will try to not create keyids like this in tuf-on-ci in the future
• It looks like out of current sigstore clients only sigstore-rs triggers this but I think I will try to fix this in root-signing-staging too -- this is not entirely trivial so won't happen immediately and the already existing root versions are unlikely to get reverted
• if the tough devs agree with the spec issue above (like I think most client devs do), we could modify the client to accept the keyids currently used