Multiple Signature Verification

[iamsamirzon]

Summary N out of M scenario; Or another way to ask Notation to verify which all identities signatures must be present. Intended Outcome The specification PR is merged Additional context This work is for N signatures out of M signatures scenarios; In the initial implementation as long as even 1 out of many signatures match, the artifact will be considered verified. This roadmap item is for adding controls to verify more than one signature

[iamsamirzon]

@priteshbandi, @FeynmanZhou - Here is a rough idea on how to use trust policy to specify which of the identity signatures must be present , for us to say a signature validation is successful. Added an optional "Must have" flag inside the identity. If the flag is not present, then existing trust policy rule hold. If the flag is present and "Must have = Yes", then a valid signature from that identity must be present for us say that signature validation is successful.

    "version": "1.0",
    "trustPolicies": [
        {
            // Policy for set of artifacts signed by Wabbit Networks
            // that are pulled from ACME Rockets repository
            "name": "wabbit-networks-images",
            "registryScopes": [
              "registry.acme-rockets.io/software/net-monitor",
              "registry.acme-rockets.io/software/net-logger"
            ],
            "signatureVerification": {
              "level" : "strict" 
            },
            "trustStores": ["wabbit-networks"],
            "trustedIdentities": [ 
              "x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Security Tools", **Must Have = No,
            ]**
            "trustedIdentities": [ 
              "x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU=Governance Team", **Must Have = Yes,
            ]**
            "trustedIdentities": [ 
              "x509.subject: C=US, ST=WA, L=Seattle, O=wabbit-networks.io, OU= Scanning Team", **Must Have = Yes,**
            ]
        },

[priteshbandi]

The json posted has a trustedIdentities key collision and it is not recommended to support key collision. Also, the example only talks about we must have a signature from A, and B, while C is optional, then why do we even need to check for C, shouldn't A and B suffice? IMO the usecase we want to support is

1. Have U signatures from at least V set of trusted identities.
2. Have X signatures from at least W set of trusted identities.