Implement and standardize a `@yubikey` decorator for CLI commands

[n-dusan]

Proposal:

Create a @yubikey decorator:

• Develop a new decorator that can be applied to any CLI command requiring YubiKey authentication.
• This decorator would automatically add --pin and --yubikey options to the command.
  • If the --pin option isn't provided when the command is executed, the decorator should prompt the user to enter their pin interactively.

Add YubiKey verification:

• Implement a check to verify that a YubiKey is inserted.
• Make sure that the correct YubiKey is being used by verifying its role or other identifying attributes.

Consistency for all commands:

• Apply the @yubikey decorator to all relevant CLI commands for a consistent UX.

Tasks

• [ ] Implement the @yubikey decorator with --pin and --yubikey options.
• [ ] Add logic to prompt for the pin if it's not provided.
• [ ] Include checks to verify Yubikey insertion and correctness.
• [ ] Apply the decorator to all relevant CLI commands.
• [ ] Test the changes on all commands to verify functionality and consistency.

[n-dusan]

What do you think @renatav? Could this be a good first issue for someone?

[renatav]

There are some complexities related to how pins are stored and used. I wouldn't say that this is a good first issue. Might even require a bit of refactoring

[renatav]

I just remembered that the pin option was removed intentionally a while back due to security concerns. I am not sure if we want to do this

[renatav]

I've been thinking about this and I can think of quite a few problems with this approach. Firstly, I'd argue that our current signing logic is more sophisticated than what is proposed in this issue. For example, if you have not inserted your yubikey, you will be asked to insert it. If it's not the correct one, you will be asked to enter a different yubikey. If the threshold is greater than 1, you will be asked to enter another yubikey. Before even trying to load the keys from the yubikey, the signing code will try to load it from keystore files. If we were to move that code to a CLI decorator, we'd also need to check which roles would need to be signed before even executing the API function and I don't like the idea of a CLI decorator handling such complex tasks. Additionally, let's say that you are adding a new delegated target role. You'll have to sign both the parent metadata and the new metadata. Also, the threshold might be greater than 1, especially if you are updating the root metadata. Additionally, we removed the pin option for security reasons.

@n-dusan Is the main problem here that it's not possible to execute these commands from a script? Can that script use the API functions and not the CLI? We could think of another way to make that possible. If that's the core issue, I'd vote for closing this issue as wontfix and opening another one.

[renatav]

Sorry, I misunderstood this. So this should not only be used in TAF, but we want to be able to import it outside of TAF? It should handle simpler cases where we know there is only one role/signing key? It's not about using it from a script? Since I was not involved in the definition of this requirement, I don't really know what the best path forward would be. It might be simple if relying on the existing yubikeys database is sufficient. If we want to handle cases like the one I listed above, I am not in favor of a CLI decorator handling it all. For whoever ends up implementing this, take a look at how load_signing_keys works