Option 1 (Preferred as disccussed) type BlobVerifierVerifyOptions struct { // SignatureMediaType is the envelope type of the signature. // Currently only `application/jose+json` and `application/cose` are // supported. SignatureMediaType string // PluginConfig is a map of plugin configs. PluginConfig map[string]string

➜ ./notation verify $IMAGE -d Warning: Always sign the artifact using digest(`@sha256:...`) rather than a tag(`:v1`) because tags are mutable and a tag reference can point to a different artifact than the one signed Resolved artifact tag `v1` to digest `sha256:cd5eef6b6a6750c9850a8d7b1a5435f35f1a1808d66c74e265f6b7ec290bea47` before signing INFO[2022-12-02T13:14:39+08:00] passing a nil signature to check 'skip' level DEBU[2022-12-02T13:14:39+08:00] verify signature against artifact referenced as localhost:5000/net-monitor@sha256:cd5eef6b6a6750c9850a8d7b1a5435f35f1a1808d66c74e265f6b7ec290bea47 DEBU[2022-12-02T13:14:39+08:00] verification level: &{Name:strict Enforcement:map[authenticTimestamp:enforce authenticity:enforce expiry:enforce integrity:enforce revocation:enforce]} ERRO[2022-12-02T13:14:39+08:00] integrity validation failed. Failure reason: unable to parse the digital signature, error : signature envelope format with media type "" is not supported INFO[2022-12-02T13:14:39+08:00] check over. not 'skip' level DEBU[2022-12-02T13:14:39+08:00] Request URL: "http://localhost:5000/v2/net-monitor/manifests/sha256:cd5eef6b6a6750c9850a8d7b1a5435f35f1a1808d66c74e265f6b7ec290bea47" DEBU[2022-12-02T13:14:39+08:00] Request method: "HEAD"

This is a continuation of [Draft] Notation Extensibility for Signing and Verification doc. Requirements The plugin's verification API MUST be signature envelope format agnostic and MUST work seamlessly with different signature envelope formats. If signature needs plugin for verification then the signature MUST convey plugin name and version required for verification. During signature verification, if the required plugin is unavailable then Notary v2 MUST fails the signature verification. :::info PR Begins - This is in early brainstorming stage

:::danger This is outdated and content has been moved to https://github.com/notaryproject/notaryproject/pull/132 ::: Update trust policy to support verification of OCI artifact signed using publicly trusted codesigning certificates. The certificates issued by CAs that are publicly trusted(abides by CAB forum guidelines and trusted by many operating systems) are referred to as publicly trusted certificates. Why do we need this change The user MUST be able to use a codesigning certificate issued from publicly trusted CAs e.g. Digicert, Entrust, Verisign, etc to sign and verify OCI artifacts. Publicly trusted CAs issue codesigning certificates to various entities from the same CA, the only way for a consumer to verify that the artifact came from a specific publisher is to pin(in trust-policy) on the publisher's signing certificate. Signing certificates have limited validity and it's recommended to rotate keys periodically. If consumer pins on the publisher's signing certificate, the rotation of the publisher's singing certificate will require all consumers to update the trust policy to pin on the new certificate.

:::danger This is outdated and content has been moved to https://github.com/notaryproject/notaryproject/pull/131 ::: Why we need this change As per signing-verfication-workflow step 3.2, if an OCI artifact contains multiple signatures, we need a mechanism to filter out the signatures based on the given trust criteria. Otherwise, we will have to download and evaluate all the associated signatures. Since there is no upper bound on the number of signatures that can be associated with an artifact, this poses an availability risk. :::info === PR BEGINS === :::

Notes :::spoiler Jan 20 2022 scoping meeting notes Repo: wabbit-networks.io/softwares Supported cases: wabbit-networks.io/software <-- repo match wabbit-networks.io/software/* <-- match immediate namespace

:::danger This is outdated and content has been moved to https://github.com/notaryproject/notaryproject/pull/122 ::: Signing workflow The user wants to sign a locally available OCI artifact and push it to a repository(along with signature). Prerequisite User has access to the signing certificate and private key.

Notary Issue #86 [TOC] This document defines the requirements for signature format and discusses the candidates for Notary V2. Terminology SignatureEnvelope($\varepsilon$): The standard data structure for storing a signed message. Signature envelope consist of following components:

Out of scope This document doesn't cover glass break mechanism required to bypass signature validation. This document assumes that here will some mechanism to revoke an artifact. The Artifact level revocation(see) design and working are out of scope. Requirements Trust Store Requirements Deployers who consumes and executes the signed artifact from a registry needs a mechanism to specify the trusted producers. This is where deployer will use Trust Store. Deployer MUST be able to specify one or more trusted signing identity(keyId, public Key, certificates, etc.).