user-defined profiles

[oncilla]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I have a couple of certificate templates that I use very frequently. I would love to be able to reference them
by a name with the --profile flag instead of providing them with the template flag.

The idea would be to place them in a specific path (e.g., the step dir) and let the CLI discover them
automatically.

I would go as far as even integrating this in the help message and tab completion. Such that it is
easy to use.

I would be happy to contribute the code to achieve this. However, I need some guidance:

1. Is this something that you would accept into the CLI?
2. Where would be a good place to put these templates?

Why is this needed?

I would like to easily share a bundle of profiles with other users and make them easy to discover in the help message and tab completion.

[hslatman]

Hey @oncilla,

This does sound like an interesting feature, but when we discussed this in our triage meeting, we decided we need some more information regarding the use case to get a clear view of a potential solution, or at least a general direction. Could you provide some more background, and the estimated number of profiles to be shared? Are you using both the CLI and CA,

Here are some of my current thoughts:

You suggest to use the --profile flag to point to a template. Hypothetically, if we were to store the template on disk, it wouldn't be that much different from having to specify the path to the template using --template, so it doesn't seem to be a big win in that regard. Besides that, the --profile flag is currently used for some fairly well-defined and hard-coded templates for specific purposes, whereas a template is more dynamic, and its contents can be changed at any time. You could say a profile is a combination of a template for a specific purpose.

Having some form of sharing templates and address those sounds like it needs some form of file sharing capability. It is not likely we'll add something like that to the CLI, unless we could use it for more purposes. It could be an option to store templates in the CA database, which would then be in charge of providing shared access to templates.

[oncilla]

Hi @hslatman

Sure. I can give a bit more detail on my concrete use case.

I'm currently a maintainer of the scion-pki tool that is used to manage certificates in the SCION Control Plane PKI. It is heavily inspired by step cli because I think you guys build a very solid tool. However, it does not have feature parity with your tool, and we do not have the resources to reach that anyway.

From my point of view, it would be a lot more beneficial to use the step tool directly, and extend it with the necessary functionality for the SCION Control Plane PKI through a scion plugin. (similar to the step kms plugin.) In fact, I have already started with a PoC in https://github.com/scionproto-contrib/step-scion-plugin and it just works ™️

Now, for the SCION CP-PKI, we require a set of profiles that is slightly different from the profiles you provide by default.
But these profiles are pretty static (has not changed in more than 4 years) and every user of the CP-PKI would need to use the same profiles. (We have 5 profiles, see scion-pki certificate create)

Hypothetically, if we were to store the template on disk, it wouldn't be that much different from having to specify the path to the template using --template, so it doesn't seem to be a big win in that regard.

I think it is different in the sense that it is a lot more ergonomic to use. If we have "named" templates that are supported in the profiles, we could allow them to be tab-completed. Also, we can refer to them with a short name (e.g., cp-as) rather than an absolute file path which can be rather long.

I also think it is not only beneficial to us, but to every user that has to define their own templates that they use often when manually creating certificates.

Having some form of sharing templates and address those sounds like it needs some form of file sharing capability. It is not likely we'll add something like that to the CLI, unless we could use it for more purposes. It could be an option to store templates in the CA database, which would then be in charge of providing shared access to templates.

In our specific case, I think sharing the files is not an issue, it can be part of the installation process (or done dynamically by invoking the scion plugin).