Document ability to revoke / remove keys

[vladimir-v-diaz]

root.json metadata is currently populated with the keys available in the keys/<role>.json files. For example, if one wishes to add a root key to root.json, the tuf gen-key root command is issued. The public key of the newly generated key is specified in root.json by gen-key. However, there isn't a command to remove a key from a specific role. I suppose one can generate a new root.json key file with only the keys desired, however, this likely requires manually editing files.

In addition, the tools should also support the ability revoke keys for specific roles (i.e., not list their public key(s) in metadata), yet still sign metadata with the revoked keys to allow clients to successfully update. The specification goes into more detail about this aspect of key revocation and management:

"To replace a compromised root key or any other top-level role key, the root role signs a new root.json file that lists the updated trusted keys for the role. When replacing root keys, an application will sign the new root.json file with both the new and old root keys until all clients are known to have obtained the new root.json file (a safe assumption is that this will be a very long time or never). There is no risk posed by continuing to sign the root.json file with revoked keys as once clients have updated they no longer trust the revoked key. This is only to ensure outdated clients remain able to update."

[titanous]

Does tuf revoke-key handle this? (#42)

[vladimir-v-diaz]

Ahh, did not know this command existed. It's not listed in the commands section of the documentation.

[titanous]

Ah, looks like that hasn't been updated recently. Do you want to update it? If not, we're happy to.

[vladimir-v-diaz]

Sure, I can update the documentation to mention tuf revoke-key. I'll also verify that it supports the use case listed in the specification, where clients are able to update after keys are revoked.

[rdimitrov]

@mnm678 - I believe we can close this one 👍

[mnm678]

Fixed by #153