Task: return pending keys ids from GET /api/v1/metadata/sign together with metadata

[MVrachev]

What is the task about?

This task is related to metadata update ceremony at the RSTUF CLI.
One of the key steps there is the authorization part.
Currently, when we do metadata update with full signing, we expect at least threshold number of keys from current root to be loaded.
Now, we cannot do the same as we have allowed our maintainers to initiate bootstrap with DAS.
My suggestion is to follow these steps for metadata DAS:

1. we load only 1 key from current root to start DAS metadata update
2. we finish metadata update
3. we store the new root as UNTRUSTED until
   a) there are current_root_threshold amount of keys loaded and signed the new root version
   b) there are new_root_threshold amount of keys loaded and signed the new root version
4. maintainers can sign new root with POST /api/v1/metadata/sign
5. when requirements 3.a) and 3.b) are met, then initiate a root rotation.

These steps are already implemented at the RSTUF worker by pr:
repository-service-tuf/repository-service-tuf-worker#355.

What I am worried is how our users will understand that they need to call POST /api/v1/metadata/sign with keys not exclusively coming from the new root version.
Imagine this situaiton:

1. DAS bootstrap ceremony was completed with threshold of 2 and 2 keys defined for root overall.
2. DAS metadata update is completed and sent to RSTUF API

• 1 key coming from current root was loaded
• new root has threshold of 3
• new root has in total 5 keys (2 keys coming from current root and 3 new keys)

4. New root is stored as UNTRUSTED
5. Two maintainers call POST /api/v1/metadata/sign with keys coming from NEW ROOT.
6. And here is the misunderstanding that happens

• maintainers think the threshold of 3 was reached and no other keys are needed (1 loaded on step 2 and 2 on step 5)
• what actually happens is that root is not considered as trusted as only requirement 3.b) is achieved and not 3.a)

A solution for this could be to make GET /api/v1/metadata/sign return not only metadata requiring signing, but the pending keyids together with root version they come from.
Example:

{
  "pending_keys": {
     {
         "keyid": "1cebe343e35f0213f6136758e6c3a8f8e1f9eeb7e47a07d5cb336462ed31dcb7"
         "root_version": 1,
     },
     {
         "keyid": "800dfb5a1982b82b7893e58035e19f414f553fc08cbb1130cfbae302a7b7fee5"
         "root_version": 2,
     },
   }
  "metadata": {
    "root": {
     ...
      }
}

References

• Feature: support distributed async threshold signing  repository-service-tuf#327

Code of Conduct

• I agree to follow this project's Code of Conduct

[MVrachev]

After a conversation with @kairoaraujo and @enyinna1234 we came up to the conclusion that those changes are not required here, but can be directly done in the CLI as it has access to the current root and has TUF installed.