Trust policy UX

[yizha1]

This is going to vary based on the user's operating system. IMO we should consider if we can get a "bare bones" cli implementation which simply writes a template similar to what's there to the user's proper directory (i.e. notation policy create -n default) and possibly opens it up or lists where it is at. (i.e. notation policy list or notation policy open (optional --name default)

Originally posted by @dtzar in #371 (comment)

[priteshbandi]

Should this be in RC2 ? We can provide commands to open trust policy in documentation and help.

[yizha1]

Should this be in RC2 ? We can provide commands to open trust policy in documentation and help.

The purpose of this issue is to agree on what we will do in RC-1. If nothing needs to be done, then we can close it. If not, we can assign people to work on it. IMO, at least documentation work needs to be done, but it's better to figure out what kind of document and where it should be put.

[priteshbandi]

For RC1: yes, we can add documentation on editing the trust policy document. But anything beyond documentation should come after RC1.

We could add documentation in getting started guide.

[yizha1]

@priteshbandi Besides documentation, we need to think about some built-in policies for users who are not admins or security experts. Some examples here just for inspiring.

• The internet explorer doesn't require normal users to manage certificates, there are pre-loaded certificates in the system, and it works by default. Advanced users can manage certificates by themselves. There are also levels of privacy control, users can choose their own and configure other options, but there will be a default one, normal user can just start using it without any configurations.

We could develop default policies for normal users, and even for a system already loaded with public certificates, users even don't need to add certificates to a trust store again (For trust store, this is not the priority right now, just for inspiring purpose).

cc: @dtzar @toddysm @shizhMSFT @vaninrao10 @iamsamirzon @gokarnm

[yizha1]

Add one idea from @FeynmanZhou

#430 (comment)

[SteveLasker]

Just a thought:
The complexity of getting the trust policy file created, with some default options feels like a great first step.
If we consider a secure by default, without TOFU, I struggle with what default roots we’d want to trust from a notation installation default.
And, even if we did, or a particular company wanted to seed their environments with a default, we likely want to make it “easy” but secure to add more trust roots and policy configurations.
Meaning, you need privileges to modify the store and policy file, but the commands should be easy to edit the files for the user. notation policy add …
Asking the user to hand edit files is likely more dangerous as it’s easy to malform the file with unexpected results.

[yizha1]

Proposal of UX improvement for a beginner:

Currently, notation cert generate-test wabbit-network does the following

• create a local key and self-signed certificate
• Add the key to signing key list with the name wabbit-network
• Add certificate to trust store with the name wabbit-network of type ca

Proposal: add a new step for notation cert generate-test wabbit-network to create a default trust policy file for the quick starter. The policy is quite simple and looks like the following:

{
    "version": "1.0",
    "trustPolicies": [
        {
            "name": "wabbit-networks",
            "registryScopes": [ "*" ],
            "signatureVerification": {
                "level" : "strict"
            },
            "trustStores": [ "ca:wabbit-networks" ],
            "trustedIdentities": [
                "*"
            ]
        }
    ]
}

With this proposal, as a beginner, the notation signing and verify experience are simplified. No need to consider how to create a trustpolicy.json file and where to store it under different OS. It's easy to do an update of trustpolicy.json for advanced users as well other than creating a new file.

The whole workflow, just four steps

$ docker push localhost:5000/net-monitor:v1
$ notation cert generate-test wabbit-networks
> output message example:
> generate a local key and add as signing key with name "wabbit-networks"
> generate X.509 self-signed certificate, and add it to trust store named "wabbit-networks" of type "ca"
> generate trust policy $HOME/.config/notation/trustpolicy.json, edit this policy file for advanced usage
$ notation sign --key "wabbit-networks" localhost:5000/net-monitor:v1
$ notation verify localhost:5000/net-monitor:v1

@priteshbandi @SteveLasker @dtzar @shizhMSFT @gokarnm @toddysm @jeremyrickard @FeynmanZhou any comments?

[dtzar]

We need to have a default template option separate from the cert generate-test command, but I agree this would be good also for the cert generate-test command.

[dtzar]

The other aspect of this is making it easier for users trust certificates they have downloaded. For instance, it could be something like:

notation cert download someregistry.io  # Adds public certificate to trust store, but doesn't add it to the trust policy
notation cert inspect someregistry.io # Displays information about the certificate itself and relevant identity information.
notation cert trust someregistry.io # Adds this certificate to the trust policy

If someone wants to "live on the wild side" and just trust whatever is there:

$notation verify someregistry.io/image:tag
Do you want to download and trust the public certificate from someregistry.io to verify? (Y/N)
$Y # Downloads public certificate to trust store, adds to trust policy file, creates trust policy file if it doesn't exist
someregistry.io certificate was downloaded, added to trust store, and trust policy
sha256:########, verification successful