Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Signature Verification #22

Open
iamsamirzon opened this issue Oct 11, 2021 · 2 comments
Open

Multiple Signature Verification #22

iamsamirzon opened this issue Oct 11, 2021 · 2 comments

Comments

@iamsamirzon
Copy link
Contributor

iamsamirzon commented Oct 11, 2021

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
Copy link
Contributor Author

iamsamirzon commented Feb 13, 2023

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

2 participants