To give an example, let's say I want to utilise insecureSkipVerify when connecting to the AWS KMS API:

witness verify --verifier-kms-ref=awskms:///arn:aws:kms:us-east-1:... --verifier-kms-aws-remote-verify=true --policy=./policy-signed.json

In this scenario, policy-signed.json will have its dsse envelope verified using remote kms verification against the KMS key awskms:///arn:aws:kms:us-east-1:... and with insecureSkipVerify=true in the TLS config as one would expect.

However, let's say that the contents of the policy dsse envelope looks something like:

      "name": "test",
      "attestations": [
        {
          "type": "https://witness.dev/attestations/command-run/v0.1",
          ...
      ],
      "functionaries": [
        {
          "type": "publickey",
          "publickeyid": "awskms:///arn:aws:kms:us-east-2:..."
        }
      ]
    }
  },
  "publickeys": {
    "awskms:///arn:aws:kms:us-east-2:...": {
      "keyid": "awskms:///arn:aws:kms:us-east-2:..."
    }
  }
}

in the functionaries field, there is one functionary that is expected to have signed any Witness collections from the test step.

During the policy verification flow, Witness will (naturally) make another network call to remotely verify the signature of any witness collection found for this step against the KMS key defined for the functionary (awskms:///arn:aws:kms:us-east-2:...). In this scenario, insecureSkipVerify=true will not be inherited from the --verifier-kms-aws-remote-verify=true flag call from the CLI.

This needs to be fixed so that any configuration of the KMS verifier set by CLI flags is inherited when verifying attestation signatures during the policy verification flow.

One way to work around this issue for now is to define the public key in a base64 encoded form in your policy (this is outlined in the documentation). This will also mean that any verifier of the policy will not need to be able to access the KMS key API endpoint, which could even be more optimal for certain users.