Fixing CA Path Flag to be used and adding policy timestamp server flag

[ChaosInTheCRD]

This PR contains a fix for the noticed bug that was discovered in that vo.PolicyCAPaths was not used in the Verify function. Note that this change working correctly is dependent on changes to https://github.com/in-toto/go-witness.

The other half of this PR focuses on allowing users to sign their policy a timestamp authority, and if they have done so, allow them to supply the CA certificate of the timestamp authority server for use in the policy verification flow. Once again this change is dependent on changes to go-witness.

This PR depends on in-toto/go-witness#124

[jkjell]

Can we add the same additional flags that Sigstore uses? https://docs.sigstore.dev/verifying/verify/#keyless-verification-using-openid-connect

--certificate-identity=name@example.com and --certificate-oidc-issuer=https://accounts.example.com

[jkjell]

We should address this todo as a part of this as well. The verification for a policy and an attestation should be the same I think.

[ChaosInTheCRD]

yeah for sure. The only difference with policy is that there isn't going to be a policy document for verifying the policy... if that makes sense. So we ought to keep the number of ways that one can use to verify the policy signature small...

[ChaosInTheCRD]

Do you think it makes sense to make all these changes in this PR?

[jkjell]

only difference with policy is that there isn't going to be a policy document for verifying the policy

I think it would be the same as the step verification: https://github.com/in-toto/go-witness/blob/main/policy/policy.go#L230

[jkjell]

We're essentially defining the functionary from the CLI

[ChaosInTheCRD]

yeah the problem though is that defining all the available parameters for the functionaries from the CLI could quickly become unwieldly imo. Consider this functionary:

        {
          "type": "root",
          "certConstraint": {
            "commonname": "*",
            "dnsnames": [
              "*"
            ],
            "emails": [
              "tpmeadows1@gmail.com"
            ],
            "organizations": [
              "*"
            ],
            "uris": [
              "*"
            ],
            "roots": [
              "wippywoo"
            ]
          }
        }

In this case, we would need to define:

1. cert-constraints (commonName, DNSName, emails, organizations, uris)
2. roots (this includes root CA cert, intermediates (which doesn't quite seem clear in the tools current form), and we might need to supply timestamp servers alongside that.

How we would present that in a flag form I am not quite sure on. To me I think that limiting support for the number of policy signing mechanisms might be the way forward? It also seems to be the case to me that TUF may be a solution to this. @kairoaraujo any thoughts?

[colek42]

I agree that it is unwieldy, however I would normally expect the user to wrap this in a bash script, or maybe a "witness verify" github action. I also think we could provide some syntactic sugar for sigstore that would let us provide better UX for the common use case while being secure by default.

ex:

for enterprise use:
witness verify -p signedpolicy.json -k ca.pem -i int.pem --commonname="*" --dnsname="*" --email="tpmeadows1@gmail.com" --organization="*" --uri="*" --root="wippywoo" artifact.tar

for sigstore:
witness verify -p signedpolicy.json --use-sigstore --use-archivista --email="tpmeadows1@gmail.com" artifact.tar

We would also need to provide a TSA pem or add support for Rekor

[ChaosInTheCRD]

This PR is dependent on in-toto/go-witness#144

[mikhailswift]

#114's been merged, can we get this updated and ready for final review?

[jkjell]

@ChaosInTheCRD I've been thinking a bit about this and I think this might be a blocker for this PR. One of the critical things to verify on a Fulcio cert is the Issuer, which is an extension we don't support yet.

[ChaosInTheCRD]

@jkjell good that you noted these custom cert extensions and I certainly think we should follow up with work to support them. However, that work is relevant to https://github.com/in-toto/go-witness, and moreover this work specifically aims to bring policy signature verification logic up to scratch with what we are currently able to use to verify attestation signatures.

Provided you're happy, I suggest we merge this PR for now. We then follow up with subsequent PRs in https://github.com/in-toto/go-witness and then finally implement it here in https://github.com/in-toto/witness.

Note that (I probably sound like a broken record, but) we need to consider how these extra custom extensions might affect the total number of flags. I think as an MVP just adding them will be fine, but I think some consideration into how we could potentially consolidate them might be worthwhile.

[ChaosInTheCRD]

What I will say however, is if you think this is high priority enough, I can expedite this and we can try and bundle it into this PR.

[netlify]

✅ Deploy Preview for witness-project canceled.

Name	Link
🔨 Latest commit	6e5265e
🔍 Latest deploy log	https://app.netlify.com/sites/witness-project/deploys/6645f4245214d00008542978

[jkjell]

Looks like we're missing a couple of test files: ./test/policy-signed.json and ./test/policy.json.

[ChaosInTheCRD]

I need to loop back over this so we can get it ready for merge. This includes factoring in in-toto/go-witness#174