How to reproduce v1.13 behaviour with v2 in a BYO PKI scenario

[lmussier]

Question
Hi I was starting to use cosign v1.13 in a bring your own PKI scenario.
And was able to sign and verify my images without any issue.

Then I've decided to move to v2 and obviously
$COSIGN verify --cert $SIGNATURE.pem --certificate-chain $CA.pem $REGISTRY$IMAGE
Does not work anymore (cf #2056 )

So my question is what I have to do to bring back the same behaviour in my context (no fulcio, no rekor).
I'm far from understanding all the things involved here but reading #2632 let le think my PKI is not 'fulcio like' and I need to wait for modifications regarding BYO PKI.

[haydentherapper]

cosign verify --certificate-chain bundle.pem --certificate cert.pem <IMAGE> is currently broken as noted in #2632. Also note that if the certificate you've provided doesn't conform to Fulcio's certificate profile, where an identity is included in it, the command will fail.

To work around this, you can do your own verification of the certificate using the chain and extract the public key to use with cosign verify --key key.pem <IMAGE>. You can use step's CLI https://smallstep.com/docs/step-cli/reference/certificate/key to do so.

[lmussier]

Also note that if the certificate you've provided doesn't conform to Fulcio's certificate profile, where an identity is included in it, the command will fail.

And this will the case even when #2632 will be fixed?

[haydentherapper]

Correct. With Cosign 2.0, we swung the pendulum more towards identity verification. We will need to think through how to do byo-pki without impacting the required checks for identity.

[Fassino]

I'm a bit confuse. Verifying Identity is of course mandatory !
But which identity?
Actually cosign looks only at subject alternative name (SAN) for this verification. Unfortunately this is not the way many private CA are working (including CA certified for critical infrastructure); They rely only on Subject name. Furthermore, i don't see the benefit of using SAN in this case, which is mainly for dealing with web server names.

Is it possible to rely identity on Subject Name also ?

[znewman01]

@Fassino I think what you're noticing is that the procedures for verifying in a BYO PKI setting and a "public Sigstore infra" setting are very different. The 2.0 release made the "public Sigstore infra" setting a lot nicer by default, but this wound up making BYO PKI worse.

At the moment, there's no easy way to rely on Subject Name; on my roadmap for the next couple months is to make this possible and a lot clearer.

[lmussier]

Hi,
Subject closed for my part.
Thanks.

[vEpiphyte]

I can across a similar behavior change with BYO PKI and wanted to note the changes I had to make.

Previously I was using the following invocation (where $IMAGETOSIGN is the reference to a given image by hash ):

$ COSIGN_EXPERIMENTAL=1 SIGSTORE_ROOT_FILE=./files/cas/fullchain.pem cosign verify --rekor-url="" $IMAGETOSIGN -a foo=bar

With 2.0.2 ( and main build as of yesterday ) that not longer works, so you have to change a few flags:

My signing certificate can be extracted with openssl ( don't need to use step ? )

$ openssl x509 -in ./files/code/DockerBuild.crt -pubkey -noout > pubkey.pem 

Then the cosign invocation can become:

$ cosign verify --insecure-ignore-sct --insecure-ignore-tlog -a foo=bar --key pubkey.pem $IMAGETOSIGN
WARNING: Skipping tlog verification is an insecure practice that lacks of transparency and auditability verification for the signature.

Verification for index.docker.io/vertexproject/xxxx@sha256:xxx --
The following checks were performed on each of these signatures:
  - The specified annotations were verified.
  - The cosign claims were validated
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"index.docker.io/vertexproject/xxxx"},"image":{"docker-manifest-digest":"sha256:xxx"},"type":"cosign container image signature"},"optional":{"Subject":"","foo":"bar"}}]