policy.json BYOPKI signature verification API

[QiWang19]

OCPNODE-2338

[QiWang19]

Hi @mtrmac , I’ve created this draft PR for the policy.json API change, could you take a look and provide your initial thoughts on the structure of the API update?
I just want to make sure I’m on the right path before proceeding further. My plan is to merge both the API and code support in a single PR. What do you think?

[mtrmac]

Thanks! Looks good overall.

Earlier discussion openshift/enhancements#1658 .

Doing both the API and implementation in one PR works for me, having the API available but broken is not really helping anything.

[QiWang19]

@mtrmac Could you please take a look? It's ready for review. I am unsure about how I’m handling the intermediate certificates.

[mtrmac]

Just a few-minute first pass — this looks very good. I didn’t read this carefully, and I skipped the tests completely, for now.

Combining the policy-provided and signature-provided intermediate certificates makes sense to me, but I’ll at least check what Cosign does.

[mtrmac]

Cc: @Honny1 as well — c/image/signature is a somewhat separate part of the codebase, and as security-critical with a lot of paranoia. Worth understanding the structure and idioms.

[QiWang19]

@mtrmac Do you think the PKI code needs a file like fulcio_cert_stub.go and should include build tags? I'm not fully clear on the purpose of this compile configuration.

[mtrmac]

The signature/*_stub.go files were added in #2180 , to avoid dependencies on sigstore Go modules not packaged (at the time??) in Debian.

Here, the only similar dependency seems to be github.com/sigstore/sigstore/pkg/cryptoutils, which is also required by no-stubbed policy_eval_sigstore.go; so this shouldn’t need a stub.

[QiWang19]

Combining the policy-provided and signature-provided intermediate certificates makes sense to me, but I’ll at least check what Cosign does.

I checked some cosign code, maybe I got lost in the code path, I did see it process the signature-provided intermediate certificates 🤔

• https://github.com/sigstore/cosign/blob/ad478088320a3c04a96b3c183bbde2205fff7bbb/cmd/cosign/cli/verify/verify.go#L248
• https://github.com/sigstore/cosign/blob/main/pkg/cosign/verify.go#L223
• https://github.com/sigstore/cosign/blob/ad478088320a3c04a96b3c183bbde2205fff7bbb/pkg/cosign/verify.go#L1332

[QiWang19]

@mtrmac could you review?

[saschagrunert]

Just two nits, otherwise LGTM

[saschagrunert]

@containers/image-maintainers can we get this merged?

[QiWang19]

@mtrmac Could you review this PR?

[QiWang19]

Rebased with the base branch.

[dmitris]

OCPNODE-2338

now tracked in RUN-2436

[dmitris]

Rebased with the base branch.

@QiWang19 could you rebase it again? (Maybe this would help to get this merged 😄 )

[mtrmac]

Looks very good overall, ~1.5 comment on the substance of the code; almost all are about testing or documentation.

[mtrmac]

Combining the policy-provided and signature-provided intermediate certificates makes sense to me, but I’ll at least check what Cosign does.

I checked some cosign code, maybe I got lost in the code path, I did see it process the signature-provided intermediate certificates 🤔

• https://github.com/sigstore/cosign/blob/ad478088320a3c04a96b3c183bbde2205fff7bbb/cmd/cosign/cli/verify/verify.go#L248

I think this is for cosign verify with an explicit --certificate option. Users usually don’t do that.

I think the relevant code path for reading signatures from the image is https://github.com/sigstore/cosign/blob/737c83c71cd42ba8db843f84beadcd59b3aa6e0a/pkg/cosign/verify.go#L822-L841 .

It is convoluted, but, effectively, if the configuration contains intermediates, the ones from the signature are ignored.

I think that behavior is unintuitive — it means that adding more configuration (possibly 100% redundant configuration) can turn accepted signatures into rejected signatures.

That code comes from sigstore/cosign#1804 , which effectively proposes to use TUF to stop accepting intermediate certificates without revoking them in any way. I don’t understand the use of intermediate certificates in this manner; it seems to me that shipping these intermediates “as trusted roots” would work well, then TUF could be used to ship a configuration update where the compromised certificate is simply dropped.

For comparison, Go’s TLS implementation takes certificates only from the protocol data, it does not allow users to provide intermediates at all.

For BYOPKI, I wouldn’t expect TUF to be used. If I’m not missing something subtle about this, let’s leave the behavior as is.

[QiWang19]

@mtrmac PTAL

[TomSweeneyRedHat]

As noted elsewhere, this is approved for RHEL 9.6/10.0 if this is merged and then backported into the c/image release-5.34 branch on or before Friday, February 28, 2024.

The Jira cards for this work are:
https://issues.redhat.com/browse/RHEL-79695 - RHEL 10
https://issues.redhat.com/browse/RHEL-79694 - RHEL 9.6

[QiWang19]

rebased with the latest branch

[dmitris]

OCPNODE-2338

^^ replaced with RUN-2436

[dmitris]

@mtrmac @QiWang19 really great that this is going to be released - thanks so much for pushing this on!

Have a question regarding the support for timestamping authority CA Roots but will add it to #2027.

[mtrmac]

Thanks! Great work.

[mtrmac]

if this is merged and then backported into the c/image release-5.34 branch on or before Friday, February 28, 2024.

@TomSweeneyRedHat I have filed #2725 for the backport.

Also, #2724 can track adding the corresponding signing code. After that, no new options should be necessary in Skopeo/Podman, just updating c/image.

[TomSweeneyRedHat]

@QiWang19 v5.34.1 release just dropped on c/image, FYI, and Happy Fri-YAY!

[QiWang19]

@TomSweeneyRedHat @mtrmac Thanks!