Add key creation, through the plugin spec

[SteveLasker]

Various keyvault providers have key vault specific APIs to create their keys.
Rather than have notary/notation understand each key vault provider, Notary follows a plugin specification, enabling plugins to define their behavior for sign, without having to engage with the notary maintainers, or ask for approval.

This issue captures the ability to call notation cert generate --plugin <name> with a set of parameters. This would enable common means for users, while the notation plugin can adapt to any notation specific formatting.

[iamsamirzon]

@SteveLasker , @dtzar - Shouldn't we keep the key creation outside of Notation. I agree the Notation should somehow refer to those keys that are used for signing , but the creation scan itself be outside of Notation.

cc: @gokarnm

[dtzar]

What Steve is referring to here though is the core plugin capability being available for notation cert generate. Agree the code to get the cert from the plugin provider should be in the plugin.

[SteveLasker]

Yes to both. It's really a matter of enabling the user to ask for a new key, through notation, but the actual implementation be done through the specific plug-in

[gokarnm]

The details of key creation, and its prerequisites are specific to each provider. Key creation may be done by a different persona, outside of the signing workflow, using provider specific tools/APIs, and may involve setting up polices for key access and rotation. It would be preferable to create keys outside notation and only use it for signing within the tool.
Adding support for key creation can also end up being a slippery slope, as ideally you would provide all management capabilities related to keys (CRUDL) for the feature to be useful.

Do we have specific scenarios this would unblock, simplify?

[SteveLasker]

Simply looking to keep the getting started process easy, and let the complex be complex.
How many different tools would a user need to get started?

[dtzar]

@gokarnm - I think it's fair to keep out of scope read/update/delete here since the command we're targeting is notation cert generate and the target user scenario is as Steve mentioned an easier getting started experience which uses a production-ready centralized/provider cert.

It would make sense if we could use the same plugin system already there (i.e. one AWS plugin or one Azure plugin), but just extend it to be able to generate a certificate via this sub-command.

[iamsamirzon]

@dtzar , @gokarnm - should the notation cert generate be independent of the plugin, in other words, built as part of the notation client itself? This way users have an even easier getting started experience and the keys can be kept locally on the host.

[dtzar]

It certainly would be a better user experience to not have to download a plugin to get a cert from the provider, but that said then you introduce a ton of dependencies into notation cli itself for every provider who wants to integrate and you lose the agility/speed to update releases of the integration independently.

An idea might be to make the installation of the plugin super simple and embed this in the notation cli. For instance:
notation plugin add azure or notation plugin add aws automatically downloads and installs the latest plugin from the plugin provider to the appropriate directory.

I feel a one-liner addition like this is a good compromise. Another alternative would be for people to independently package the notation bits along with the plugin together, but that's a lot of maintenance work on every plugin provider to maintain in notaryproject org repo(s).

[vaninrao10]

As discussed in the community meeting "09/15" to be moved to Post RC1.

[yizha1]

@SteveLasker Is this issue still valid since no activities for almost one year?

[SteveLasker]

I defer to the providers to decide the importance. We can close this, pending their request.