TUF CLI: Improve experience by allowing offline signature generation

[asraa]

This would help using the TUF CLI in more tightly controlled key environments, e.g. an air-gapped situation.

I propose two methods:

tuf payload <role> that outputs the canonicalized, signable content of the role's metadata file
tuf add-signature <role> --signature <sig_file> that adds a signature (hex-encoded bytes), generated by an offline tool, to the role. This should verify the signature first.

@haydentherapper

[haydentherapper]

Definitely like this approach! It mirrors what you might do with offline signing of a CSR for X509, where a service generates a CSR and you take just the CSR to an offline key to sign it.

This will also avoid requiring two TUF repos set up, one for online and one for offline.

[asraa]

/assign @znewman01

[joshuagl]

If you comment here @znewman01 we can assign you the issue.

[znewman01]

commenting!

[znewman01]

@asraa I see discussion in #213 about support for key imports etc. Can you clarify for this issue: when you say signed with an "offline tool" what do you mean:

1. Signed with e.g. the openssl CLI? If so, we need key imports in the CLI (or exports but that feels backwards) so openssl can get the key.

2. Signed with go-tuf CLI? If so, specifically how (how do we avoid having an offline repo)?

(Hopefully my question makes sense.)

[asraa]

Sure! Admittedly I think there's some confusion between the CLI/exposed API...

Signed with e.g. the openssl CLI? If so, we need key imports in the CLI (or exports but that feels backwards) so openssl can get the key.

Yeah, I think we need public key imports via CLI (a method already exists for this in the API -- AddVerificationKey) to make this work. In root-signing none of the private key material is held in the TUF repo. We use the AddVerificationKey method to add the keys to the repo. So in your offline repo you have your private key material, export it and deliver it to the online repo that Adds it to a role, and then you can use the payload generation/add signature flow.

The purpose of the payload command would be to avoid having to manually marshal the metadata into the signable payload (I do this here in root-signing). Right now there's no public API to create and access this, and its caused me a problem with verification before when I've done it incorrectly (sigstore/root-signing@02a7fb4)