nv2 sign to add subject annotation, with consumption within verify

[SteveLasker]

To support filtering and targeting the specifically referenced artifact, we discussed adding an annotation to the manifest: https://github.com/SteveLasker/artifacts/blob/oci-artifact-manifest/artifact-manifest/net-monitor-image-signature.json

"annotations": {
    "org.cncf.notary.v2.signature.subject": "wabbit-networks.io"
  }

The nv2 client can filter artifacts in the referrers API, then further filter the subset of signature manifests to ones the client needs to actual fetch. This further limits having to pull the blob for each referenced artifact

[shizhMSFT]

This effort will be included in prototype-3.

[shizhMSFT]

@SteveLasker The annotation org.cncf.notary.v2.signature.subject is ambiguous here since it can be one of the following

1. Common Name (CN) of the signature signer.
2. The declared reference name of the signed artifact.

Here is an example: A signer with the private key of the cert with CN=wabbit-networks.io signs an image wabbit-dev.com/monitor:v1 with declared reference wabbit-prod.com/monitor:v1. Which value should the annotation be?

• wabbit-networks.io?
• wabbit-dev.com?
• wabbit-prod.com?

[shizhMSFT]

Besides, how do the clients know the org.cncf.notary.v2.signature.subject value in advance to do filtering?

Assuming CN is the annotation value, unless the client pins a certain set of names, the clients should download all signatures.

[SteveLasker]

how do the clients know the org.cncf.notary.v2.signature.subject value in advance to do filtering?

This will be part of the notary v2 spec, to state that signatures must set the value. As for whether to use subject, or another named element and what value to use, I defer to our crypto/key experts. The purpose here is how can an nv2 client determine which artifactType of cncf.notary.v2 signatures should it pull?

[shizhMSFT]

Pop out the Common Name (CN) from the certificate associated with the verification key to the annotations field might be a good idea. /cc @gokarnm

[shizhMSFT]

Another question for @SteveLasker is why we store the annotations at the manifest blob level instead of the blobs level.

For example:

{
    "schemaVersion": 3,
    "mediaType": "application/vnd.oci.artifact.reftype.manifest.v1+json",
    "artifactType": "cncf.notary.v2-rc1",
    "blobs": [
        {
            "mediaType": "application/tar",
            "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0",
            "size": 32654,
            "annotations": {
                "org.cncf.notary.v2.signature.subject": "wabbit-networks.io"
            }
        }
    ],
    "subjectManifest": {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "digest": "sha256:73c803930ea3ba1e54bc25c2bdc53edd0284c62ed651fe7b00369da519a3c333",
        "size": 16724
    }
}

[iamsamirzon]

There are two reasons to defer this after the first release

1. We have another way of filtering with certificate fingerprints.
2. The Gatekeeper timeout is no longer a restriction of finishing verification in < 3 seconds.

[SteveLasker]

Keeping active to surface key information in the manifest, without having to read into the blobs. The information should human readable content to understand which key should be pulled.

[github-actions[bot]]

This issue is stale because it has been opened for 60 days with no activity. Remove stale label or comment. Otherwise, it will be closed in 30 days.