Skip to content
99 changes: 99 additions & 0 deletions specs/commandline/verify.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
# notation verify

## Description

Use `notation verify` command to verify signatures on an artifact. Signature verification succeeds if verification succeeds for at least one of the signatures associated with the artifact. The digest of the supplied artifact is returned upon successful verification. It is recommended that this digest reference be used to pull the artifact subsequently, as registry tags may be mutable, and a tag reference can point to a different artifact that what was verified.

## Outline

```text
Verify signatures associated with the artifact.

Usage:
notation verify [flags] <reference>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should explain here and in the sign command that < reference > support can be a tag or a digest. When with a tag, we do a default tag to digest translation and we only sign/verify the digest, not the tag itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will create a new PR to address this


Flags:
-h, --help help for verify
-p, --password string Password for registry operations (default to $NOTATION_PASSWORD if not specified)
--plugin-config strings {key}={value} pairs that are passed as is to a plugin, if the verification is associated with a verification plugin, refer plugin documentation to set appropriate values
-u, --username string Username for registry operations (default to $NOTATION_USERNAME if not specified)
```

## Usage

Pre-requisite: User needs to configure trust store and trust policy properly before using `notation verify` command.

### Configure Trust Store

Use `notation certificate` command to configure trust stores.

### Configure Trust Policy

Users who consume signed artifact from a registry use the trust policy to specify trusted identities which sign the artifacts, and level of signature verification to use. The trust policy is a JSON document. User needs to create a file named `trustpolicy.json` under `{NOTATION_CONFIG}`. See [Notation Directory Structure](https://github.com/notaryproject/notation/blob/main/specs/directory.md) for `{NOTATION_CONFIG}`.

An example of `trustpolicy.json`:

```jsonc
{
"version": "1.0",
"trustPolicies": [
{
// Policy for all artifacts, from any registry location.
"name": "wabbit-networks-images", // Name of the policy.
"registryScopes": [ "*" ], // The registry artifacts to which the policy applies.
"signatureVerification": { // The level of verification - strict, permissive, audit, skip.
"level": "strict"
},
"trustStores": [ "ca:wabbit-networks" ], // The trust stores that contains the X.509 trusted roots.
"trustedIdentities": [ // Identities that are trusted to sign the artifact.
"x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Finance, CN=SecureBuilder"
]
}
]
}
```

In this example, only one policy is configured with the name `wabbit-networks-images`. With the value of property `registryScopes` set to `*`, this policy applies to all artifacts from any registry location. User can configure multiple trust policies for different scenarios. See [Trust Policy Schema and properties](https://github.com/notaryproject/notaryproject/blob/main/trust-store-trust-policy-specification.md#trust-policy) for details.

### Verify signatures on a container image stored in a registry (Neither trust store nor trust policy is configured yet)

```shell

# Prerequisites: Signatures are stored in a registry referencing the signed container image

# Configure trust store by adding a certificate file into trust store named "wabbit-network" of type "ca"
notation certificate add --type ca --store wabbit-networks wabbit-networks.crt

# Configure trust policy by creating a JSON document named "trustpolicy.json" under directory "{NOTATION_CONFIG}"
# Example on Linux
cat <<EOF > $HOME/.config/notation/trustpolicy.json
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will create a new issue for a discussion regarding this request.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{
"version": "1.0",
"trustPolicies": [
{
"name": "wabbit-networks-images", // Name of the policy.
"registryScopes": [ "registry.wabbit-networks.io/software/net-monitor" ], // The registry artifacts to which the policy applies.
"signatureVerification": { // The level of verification - strict, permissive, audit, skip.
"level" : "strict"
},
"trustStores": [ "ca:wabbit-networks" ], // The trust stores that contains the X.509 trusted roots.
"trustedIdentities": [ // Identities that are trusted to sign the artifact.
"x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Finance, CN=SecureBuilder"
]
}
]
}
EOF

# Verify signatures on a container image
notation verify registry.wabbit-networks.io/software/net-monitor:v1
```

### Verify signatures on an OCI artifact stored in a registry (Trust store and trust policy are configured properly)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing as to OCI artifact versus trust * configured versus not.
I'd consider removing the distinction of OCI artifact per section. Place the tag AND digest verification options for image & OCI artifact in the same properly configured section.

I'd then have a section on what the experience is like when trust store and policy is not configured. I'd imagine you wouldn't get a verification, but show some error message(s).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will create a new PR to address this comment and the error handling parts.


```shell
# Prerequisites: Signatures are stored in a registry referencing the signed OCI artifact

# Verify signatures on an OCI artifact identified by the digest
notation verify registry.wabbit-networks.io/software/net-monitor@sha256:abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234
```