Signing with local private keys

[ningziwen]

What is the areas you would like to add the new feature to?

Notation CLI

Is your feature request related to a problem?

Based on the discussion, Notation is not supporting signing with local private keys except the testing only keys, and will support it in the future.

I understand current plugin approach is more secure which can manage the private keys for users, but I'd like to see local private key feature as a less advanced feature than current plugin approach, which gives users more flexibility to onboard to existing key management workflow.

What solution do you propose?

• Not exact a completed solution. I'd like to discuss the external interface first before the detailed design.
• I also like alternative 2. Want to get community's input.

The current workflow is Notation is to manage the key in a separated store, and let sign use the key from the store. To be compatible with current workflow, the intuitive way is to add local private key to the key store.

1. Add a special plugin value "none" (or other better name) to state the key is from local.
2. Add a new flag "key-file" to pass the local key file.

notation key add --plugin none --key-file <key_file_path> <key_name>
notation key add --plugin none --key-file key.key my_key

What alternatives have you considered?

1. Bypass the key store workflow. Directly make --key-file part of sign

notation sign --key-file <key_file_path> <reference>

Even we don't choose this alternative, the alternative could be an improvement of proposed solution.

2. Add a very simple build-in plugin for local key file.

The good thing is no special value is needed. The plugin can be called "local" and has only one args --key-file with only one feature of providing local key file.

Any additional context?

I'm happy to contribute this feature when we reach a concensus.

[yizha1]

@ningziwen Thank you for this initiative. Contribution to this project is always welcome! I have some questions about local private key. Could you provide more details about your scenario, for example, where does this local private key come from? Does notation generate it? How can we be sure the right local key is used for signing? /cc @priteshbandi @shizhMSFT for further discussion.

[ningziwen]

@yizha1 The "local private key" is managed by the users with any customized workflow as they have. Notation doesn't generate it. If the users choose to manage the private key by themselves with choosing "local private key", they will have the responsibilty to make sure they are using the right key. Again, this is not the most secure/best experience solution, but will just make it more flexible by providing an alternative for users to choose.

(If this doesn't align notation's goal or tenets --- for example, if notation only wants to provide the solutions that can help users manage the keys securely, please let me know. That can also help me understand notation better, and we can see if there is anything we may add to the doc to clarify the goals/tenets.)

[ningziwen]

Finding: the local private key and cert can be used by manually changing signingkeys.json. https://notaryproject.dev/docs/how-to/notation-config-file/#sample-of-signingkeysjson

So the core functionality is already there and there is just no relevant CLI command. So the question becomes, do you think it is valuable to add CLI command for this so users don't have to manually chagne the signingkeys.json?

[yizha1]

@ningziwen It is valuable to support signing with local private key, and use CLI command for better UX. The concern is more about how we can safely use the local private key. For example, how to protect the local key? If the local key is compromised, what mitigation could we take? It's better to consider the security threats that using local private key must face. Local key support is also on the roadmap, check this issue notaryproject/roadmap#44. If it is OK for you, I will invite you to the community meeting to discuss your solution to this issue.

[ningziwen]

@yizha1 Yeah sounds good. It may take some time to prepare the doc. Is it a place to sign up the community meeting agenda by myself? If not, I will ping you when I'm ready.

[yizha1]

@ningziwen You can ping me when you are ready. The community meeting schedule can be found here https://www.cncf.io/calendar/.

[CalebSchwartz]

We are utilizing an ADO pipeline and are wanting to sign our images (among other artifacts) utilizing notation. We would like to be able to load the x509 certificate and key from ADO's secure files during our CI/CD pipeline. Today you can load the certiifcate using notation certificate add and would like that same functionality to exist for notation key add instead of requiring use of a plugin.

[FeynmanZhou]

I have a similar feature to this one. Linking #905

[rennerg]

Any movement on this? Or at least a workaround? We am not able to load certs and keys from a key vault and must pull them from ADO secure files. Specifying the key and cert by file path instead of via a plugin would unblock us.

[yizha1]

@rennerg this enhancement is not planned in near milestones. A workaround (not recommended for production) is to update configuration file named signingkeys.json with similar configuration as following. This file is under {NOTATION_CONFIG}. See Notation directory structure.

{
    "default": "<Your_Name>",
    "keys": [
        {
            "name": "<Your_Name>",
            "keyPath": "<Absolute_path_key>",
            "certPath": "<Aboslute_path_cert>"
        }
    ]
}

You should be able to list the key you just added

notation key ls

As the key is set as default key, so you can use notation sign directly, for example

notation sign $image

if you added multiple keys and you want to use a different key, you can use the following command:

notation sign $image --key <KEY_NAME>

Please give it a try and let me know whether it works or not.