Feature: Support "keyless" verification non-Fulcio certificate authorities

[nsmith5]

Description

Currently we have some support for signing with x509 certificates using haven't come from a Fulcio CA and and don't chain up to a TUF root. For example

cosign sign --certificate cert.pem --key key.pem --certificate-chain bundle.pem example.com/foo@sha256:.....

Aside: the key format needs to be cosign's format to make this work so you often need to run e.g cosign import-key-pair to make that the case

The current invocation to verify this kind of signature is a little inconvenient as you need to specify the leaf certificate like so:

cosign verify --certificate cert.pem --certificate-chain bundle.pem example.com/foo@sha256:....

This means grabbing that leaf certificate off the OCI manifest or from the Rekor bundle or something. Would be great to be able to do the same kind of invocation as Fulcio's verification like

cosign verify --certificate-chain bundle.pem --certificate-identity foo@example.com --certificate-oidc-issuer https://id.example.com example.com/foo@sha256:.....

This convenient keyless verification would be awesome for folks using a custom CA, provided they're using certificates in a similar shape that Fulcio does (Efforts to standardize these extensions like sigstore/fulcio#945 would make it easy for folks to create a CA that does this)

[haydentherapper]

cc @znewman01 since we were chatting about this recently

We definitely need a cohesive story around BYO PKI UX, since issues like this have popped up a few times. This seems like a reasonable approach, though I personally would prefer we encourage TUF usage over passing roots by flag. It's not difficult to set up a TUF repo, and it offers far more secure methods of managing root key material in one's PKI.

[nsmith5]

Yeah I agree that passing roots by file is less secure and we should encourage folks to set up a TUF root for distribution if possible, but I think its would be nice to keep the option there even if its got the usual discouraging name like --insecure-certificate-chain with a little pointer to how folks can do better with TUF. Also, I think its reasonable that folks might have some other secure mechanism to deliver a CA bundle without requiring cosign to do that bit.

[haydentherapper]

One thing that Zack proposed that I liked was namespacing verification with self hosted PKI. This would let us be opinionated about TUF for some verification, but allow for other verification for the BYO case. This lets us avoid calling parts of verification insecure since there’s an assumption that you know what you’re doing with self hosted.

This would be a ways out obviously so adding this flag seems reasonable.

[nsmith5]

Is the idea with namespacing self-hosted PKI to split it off into its own subcommand like e.g cosign verify-with-pki (can't think of a good name 😆 ) so that the flags and options of BYO PKI are on a whole different command? Or do you mean moving the verification logic when --certificate-chain is specified to a seperate package in the repo to split up the implementation more clearly?

[haydentherapper]

A different set of CLI commands with their own flags. The verification API should be designed to support any use case (it shouldn’t be TUF aware for example, the CLI layer should just parse the input and pass it to the verifiers).

Main concern with this approach is creating even more verify functions, we already have a lot!

[nsmith5]

Yeah agreed that the verify functions are kind of a lot, but I will say that the user experience might be better if BYO PKI has its own subcommand. I've been playing around with this BYO PKI using a step-ca configured to look kinda like Fulcio that respects OIDC tokens from my Gitea instance and I found it really tricky to understand which flags on the existing verify function worked together as there are so many ones you'd think might combine or might not you know?

[haydentherapper]

Flag bloat is definitely an issue. Tangential, I’m curious what the verify command looked like and how we can simplify.

[nsmith5]

So the flow right now looks like this

# Build example image with ko
KO_DOCKER_REPO=code.nfsmith.ca/nsmith/seccon ko build --bare > image

# Get a code signing cert from my step-ca
step ca certificate code@nfsmith.ca cert.pem key.pem

# Import the private key to the cosign format. (Lets get rid of this odd step in the BYO PKI experience? I'm going to delete the key right after this anyways..)
COSIGN_PASSWORD=derp cosign import-key-pair --key key.pem

# Signing
COSIGN_PASSWORD=derp cosign sign --key import-cosign.key --certificate cert.pem \
    --certificate-chain bundle.pem $(cat image)

# Delete private key
rm import-cosign.key key.pem

# Verification
cosign verify --certificate cert.pem --certificate-chain bundle.pem --certificate-identity code@nfsmith.ca --certificate-oidc-issuer https://code.nfsmith.ca/ --insecure-ignore-sct $(cat image)

The last bit works because of the structure of my step-ca configuration. Its adding the right Fulcio extension so that --certificate-oidc-issuer flag works correctly.

I think ideally I'd like to smooth out the experience to by

• Removing the need to change the private key format
• Removing the need to specify the certificate when verifying
• Make the verification logic more extensible if its a custom CA?

On that last note, it was easy to make step-ca kind of Fulcio-like to fit the need here, but it would be nice if cosign verify-with-pki (or whatever) could read something like a Rego policy and I could write down the checks I wanted there so that a user could check any number of custom extensions etc

[haydentherapper]

Removing the need to specify the certificate when verifying

To confirm, does your OCI image have the certificate and chain in its annotations? If you pass them on sign, they should get attached to the image so you don't need to provide --certificate (you still need --certificate-chain, though technically you only need the root since the intermediates get pulled from the image annotations if not specified by flag).

[nsmith5]

Yup! Sign totally works as expected and I can see the cert and chain correctly added to the OCI signature when I run e.g `crane manifest derp:sha256-blah.sig`

[nsmith5]

Should is the key word I guess. It doesn't work in practice because if you don't specify a cert then the current cosign implementation loads the Fulcio root, ignores the cert chain you specify and then fails verification because it didn't load the CA chain correctly