re-evaluate succinct key design

[jku]

current succinct delegation process has threeparts

• create delegation
• create delegation key (store it for each delegated role)
• initialize metadata for each delegated role

but only two commands:

tufrepo edit demo add-delegation --succinct 256 demo-bin
tufrepo init-succinct-roles demo

this works but the key is now magic that happens without user having any control: init-succinct-roles creates it -- but we don't know if user actually wanted a new key or not, and user might not even notice that a key was created... I think it would make sense if the key-step was separate just like it is for other delegations:

tufrepo edit demo add-delegation --succinct 256 demo-bin
tufrepo edit demo add-key
tufrepo init-succinct-roles demo

this would require two changes:

• add-key would not need "delegate" argument iff the delegation is succinct (but would need to store the key in keyring for each delegated role)
• ini-succinct-roles should stop doing anything with keys

[jku]

cc @MVrachev for comment

[MVrachev]

I think you have a point that the behavior for succinct hash bin delegation should be the same as when delegating to a standard delegation. It makes sense to split the process in three steps given how important is a key addition.

About that:

add-key would not need "delegate" argument iff the delegation is succinct (but would need to store the key in keyring for each delegated role) that's easy to do as we are actually doing that in init-succinct-role: https://github.com/vmware-labs/repository-editor-for-tuf/blob/9896bcf2606307276a7bf9a217e8c6a187b1fe97/tufrepo/cli.py#L142-L145

[MVrachev]

I will work on that.