feat: multiple signatures verification

[yizha1]

What would you like to be added?

A container image could be signed by one trust identity multiple times, or by multiple trust identities, either case will produce multiple signatures associated with the image.

Trust identity is the identity that the signer trusts, for X.509 PKI, it means the signing certificate subject. For example, "C=US, ST=WA, L=Seattle, O=acme-rockets.io, OU=Finance, CN=SecureBuilder".

Scenario 1: A container image was signed by the same trust identity multiple times.

A container image was signed by different teams in the same company wabbit networks. For example, the builder team built the container image and signed it by adding annotation build=123. Then the QA team verified it and signed it using the same signing certificate but adding a different annotation test=123. Then this image had two signatures from the same trust identity with different annotation

Scenario 2: A container image was signed by multiple identities

• A container image was signed by different teams in the same company Wabbit Networks, for example, the builder team built the container image and signed it, QA team verify it and signed it again using a different signing certificate before promoted to production. Then this image had two signatures from different trust identities from the same company.

• A container image was signed by the company Wabbit Networks and published to a public registry. The company ACME Rockets only allows verified images to be used by internal teams. The acquiring team of the company ACME Rockets verified the image and signed the image, and then pushed it into internal registry. This image had two signatures from different trust identities from different companies.

• A container image was signed by the company Wabbit Networks using tooling cosign and published to a public registry. The company ACME Rockets only allows verified images to be used by internal teams. The acquiring team of the company ACME Rockets verified the image, signed the image using tooling notation and pushed it to internal registries. Both cosign and notation can sign images but produce different formats of signatures. This image had two signatures with different formats.

Ratify policy for multiple signatures verification

Ratify policy should be able to support multiple signatures verification, so that users have a fine-tuned policy for validating signatures based on different scenarios.

• Pass verification by 1 signature out of N signatures. The trust identity could be one from a trust identity list or any identity
• Pass verification by N signatures from out of M signatures, each of the N signatures has a different trust identity

Scenario-1 has lower priority than Scenario-2.

Anything else you would like to add?

The solution could be related to feature multiple verifiers that covered by this issue #448

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[akashsinghal]

For a small company, both teams could use the same signing certificate, but added different annotations to the signature payload.

@yizha1 This is an interesting scenario. We hadn't considered annotations being used in policy. Currently, Ratify generates verification reports that contain details at the artifact level. For notation, for example, the report looks like this:

{
  "isSuccess": true,
  "verifierReports": [
    {
      "subject": "artifactstest.azurecr.io/resource-1-5sigs100subjects@sha256:06a076a09592b744cdbd3f87cc54c15d4f5ef9be47626261c1b002291edb0b51",
      "isSuccess": true,
      "name": "notaryv2",
      "message": "signature verification success",
      "extensions": {
        "Issuer": "CN=wabbit-networks.io,O=Notary,L=Seattle,ST=WA,C=US",
        "SN": "CN=wabbit-networks.io,O=Notary,L=Seattle,ST=WA,C=US"
      },
      "artifactType": "application/vnd.cncf.notary.signature"
    }]
}

The notation verifier adds some custom fields such as the Issue and SN. If a user is adding custom annotations to their sigs, then they'd want those annotations showing up in the artifact's verifier report so that the rego policy can consider that.

Few follow up questions:

• Does notation cli support custom annotations?
• Is adding the annotations of the artifact a verifier-specific implementation detail? or is it a global verifier report addition that should be added regardless of the verifier run?

[yizha1]

@akashsinghal

Few follow up questions:

• Does notation cli support custom annotations?
• Is adding the annotations of the artifact a verifier-specific implementation detail? or is it a global verifier report addition that should be added regardless of the verifier run?

@akashsinghal

1. notation supports signing and verifying artifacts with user-metadata (annotation added to signature payload), see signing example and verifying example
2. It's for notation only.

I missed one scenario, it is about a container image that is signed by multiple signing tools, for example cosign and notation, which results multiple signatures as well. I will update the issue soon.

[binbin-li]

Synced with @yizha1 offline.

For scenerio 1, Ratify could support it by passing required annotations to the UserMetadata field of VerifyOptions. However, if there are different annotations for different parties, then Ratify has to verify a signature using those annotations one by one, which could incur too many redundant verification processes. As discussed offline, Yi will gather more info on this scenerio to see how we would support it.

For scenerio 2 and 3, they would be supported by the refactored policy provider by providing corresponding Rego policies.

[akashsinghal]

Thanks @yizha1 for pointing me to the user metadata functionality. I wasn't aware this was supported. @binbin-li do you think Ratify would need to add the user annotation to verifier report so that policy could be applied?

[binbin-li]

those annotations are verified by notation verifier not by the OPA engine. Adding it to verifier report might not help the scenario, but we can still add it to extensions field. Instead, it should be added in verifier config or somewhere else that can be updated dynamically.

[yizha1]

@binbin-li I updated the issue description and added one case for scenario-2. Scenario-1 is less important than scenario-2

[binbin-li]

Discussed with @yizha1, Ratify already supports it via Rego Policy. But we need to provide some templates for the below scenarios to help users try it:

1. Multiple signatures are signed by different signing keys issued by the same root CA.
2. Multiple signatures are signed by different signing keys issued by different root CAs.