feat: Decouple signing

[udf2457]

Is your feature request related to a problem? Please describe.

From my brief reading of the metadata code, at present your library appears to make the same mistake as theupdateframework/go-tuf in that key signing is tighly coupled to primitive and crude on-disk keyfiles.

This means that real-world secure key storage such as PKCS#11 (theupdateframework/go-tuf#427), AWS KMS (theupdateframework/go-tuf#525) and others e.g. Yubikey are not readily supported and require hacky work-around kludges to work (e.g. manually hacking json files).

Describe the solution you'd like

Of course support for signing from local keyfiles stored on disk should remain, but integration with real world applications where the private key is stored in a non-exfilterable format should be supported.

Describe alternatives you've considered

No response

Additional context

No response

[MDr164]

Sounds like a good idea, we should create a signer package that simply takes in bytes and outputs signed bytes instead of signing only files.

[rdimitrov]

@udf2457 - It is definitely something we should have in go-tuf/go-tuf-metadata 👍 I'm supportive of refactoring the existing signer mechanism to incorporate such support. Let me know if I can help you or someone else who is interested in contributing with that. Currently we are finalising the testing (@MDr164 and @ivanayov helped a lot) and eventually we'll start copying the codebase to go-tuf where they'll live in parallel for a start so it's less of a change. I can try to squeeze something else in my agenda but unfortunately I cannot promise anything, at least for next few weeks.

[jku]

For reference, in python-tuf we ended up with https://github.com/secure-systems-lab/securesystemslib/tree/main/securesystemslib/signer: It's certainly not perfect but manages to support yubikeys, 3 different KMSs, sigstore (experimentally), etc

The documentation is not as good as it should be but if someone starts thinking about this issue in go-tuf-metadata, feel free to ping me or @lukpueh for some consultation

[rdimitrov]

Closing in favour of theupdateframework/go-tuf#594