Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify the certificate chain against the Fulcio root trust by default #2139

Merged
merged 3 commits into from Aug 9, 2022

Conversation

wata727
Copy link
Contributor

@wata727 wata727 commented Aug 6, 2022

Summary

See #2134

Currently, the verification performed by cosign verify-blob --cert does not verify the certificate chain, so you cannot guarantee that the certificate was correctly issued by Fulcio. So you need to explicitly pass Fulcio's root certificate via the --cert-chain option.

cosign initialize
cat ~/.sigstore/root/targets/fulcio_intermediate_v1.crt.pem > fulcio_chained.crt.pem
echo >> fulcio_chained.crt.pem
cat ~/.sigstore/root/targets/fulcio.crt.pem >> fulcio_chained.crt.pem
echo >> fulcio_chained.crt.pem
cat ~/.sigstore/root/targets/fulcio_v1.crt.pem >> fulcio_chained.crt.pem

cosign verify-blob --cert checksum.txt.pem --cert-chanin fulcio_chained.crt.pem ...

However, this way of getting root certificates is not secure. Ideally, it should be retrieved by a TUF client. After discussing this matter in #2134, @haydentherapper says that there is room for changing the default behavior.

This PR will change the default behavior from not verifying the certificate chain if --cert-chain is not passed to verifying the certificate chain against the Fulcio root trust getting by a TUF client.

Release Note

  • Changed the default behavior from not verifying the certificate chain if --cert-chain is not passed to verifying the certificate chain against the Fulcio root trust getting by a TUF client.

Documentation

  • The description of the --certificate option needs to be changed.

@wata727
Copy link
Contributor Author

wata727 commented Aug 6, 2022

I have two things to discuss:

  • Should this change be followed by similar commands such as cosign verify?
  • Is there a good way to add tests for this implementation? verify_blob_test.go didn't seem to have any tests for verification.

Signed-off-by: Kazuma Watanabe <watassbass@gmail.com>
@wata727 wata727 force-pushed the verify_cert_chain_by_default branch from d43c022 to ce81d79 Compare August 6, 2022 09:26
@codecov-commenter
Copy link

codecov-commenter commented Aug 6, 2022

Codecov Report

Merging #2139 (b4887ea) into main (128f8fb) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2139      +/-   ##
==========================================
- Coverage   26.28%   26.23%   -0.06%     
==========================================
  Files         130      130              
  Lines        7602     7617      +15     
==========================================
  Hits         1998     1998              
- Misses       5347     5362      +15     
  Partials      257      257              
Impacted Files Coverage Δ
cmd/cosign/cli/options/certificate.go 0.00% <0.00%> (ø)
cmd/cosign/cli/verify/verify.go 0.00% <0.00%> (ø)
cmd/cosign/cli/verify/verify_attestation.go 0.00% <0.00%> (ø)
cmd/cosign/cli/verify/verify_blob.go 9.72% <0.00%> (-0.16%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Contributor

@haydentherapper haydentherapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cmd/cosign/cli/verify/verify_blob.go Show resolved Hide resolved
@haydentherapper
Copy link
Contributor

Testing is unfortunately a bit rough. Check out e2e_test.go, but it might be hard to fit in a test for this, especially with TUF. We may need a TODO.

@haydentherapper
Copy link
Contributor

/hold, I want to give a bit more thought to this and will get back to you on Monday.

cc @znewman01

…default

Signed-off-by: Kazuma Watanabe <watassbass@gmail.com>
…ust by default

Signed-off-by: Kazuma Watanabe <watassbass@gmail.com>
@wata727
Copy link
Contributor Author

wata727 commented Aug 7, 2022

The same changes need to be made

Fixed eda267b

Testing is unfortunately a bit rough. Check out e2e_test.go, but it might be hard to fit in a test for this, especially with TUF. We may need a TODO.

Understood. I'll take a little deeper look at the e2e_test.go implementation.

@wata727 wata727 changed the title verify-blob: Verify the certificate chain against the Fulcio root trust by default Verify the certificate chain against the Fulcio root trust by default Aug 7, 2022
@wata727 wata727 marked this pull request as ready for review August 7, 2022 16:31
@znewman01
Copy link
Contributor

Hey, thanks for this! (and thanks for looping me in, @haydentherapper)

I haven't looked too closely at the code but this change seems like much better/safer default behavior.

I just want to think through workarounds for anyone who was relying on the old behavior. The right thing to do in such a case is probably to provide the public key directly, rather than via a cert; this makes it much clearer what you're asking for. Maybe we should refer users to the step certificate key command? IIUC it should Just Work™

Was there anything specific you wanted my feedback on?

@patflynn
Copy link

patflynn commented Aug 9, 2022

I'm probably mis-interpreting this, but for cases where the user has signed a blob with a user provided custom key, why would we want to verify against the fulcio root?

@haydentherapper
Copy link
Contributor

haydentherapper commented Aug 9, 2022

@znewman01 Just looking for a second opinion! Generally this looked good to me, beyond the potentially breaking change.

@patflynn One thought is a user is very unlikely to provide a certificate in that case (I think), they'd be providing a key. We've got a few options for providing verification material:

  • No key or cert - Either:
    • Fetch the certificate+chain from OCI. Verify the certificate+chain against the TUF root
    • Fetch the certificate from Rekor for blob signing. Extract the verification key. (I don't actually like this since Rekor is meant to be a witness to an event and not storage, but let's discuss that more in another issue) <-- Note that this doesn't verify the cert against a chain because previously Rekor didn't support uploading the full cert chain. This option is just kinda messy.
  • A key - Use the key to verify
  • A certificate+chain - Verify the chain, and extract the verification key from the cert. Don't verify against TUF.
  • A certificate w/o chain - Current behavior is to just extract the verification key. My question is, is anyone providing a certificate that's not from Fulcio in this case? If the vast majority of users provide a Fulcio certificate, then we should verify against the chain from TUF.

The workaround would either be extracting the key themselves (Like Zach mentioned) or providing the full certificate chain.

@patflynn
Copy link

patflynn commented Aug 9, 2022

@haydentherapper got it. that makes sense. Thanks for clarifying.

@@ -37,7 +37,7 @@ var _ Interface = (*RekorOptions)(nil)
// AddFlags implements Interface
func (o *CertVerifyOptions) AddFlags(cmd *cobra.Command) {
cmd.Flags().StringVar(&o.Cert, "certificate", "",
"path to the public certificate")
"path to the public certificate. The certificate will be verified against the Fulcio roots if the --certificate-chain option is not passed.")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Fulcio root provided in the TUF root?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't mention it to TUF here because I have a concern about the description would be too long. If we should mention it, please let me know so I fix it.

@haydentherapper
Copy link
Contributor

LGTM, just need to fix the failing test. Thanks!

@dlorenc
Copy link
Member

dlorenc commented Aug 9, 2022

The failure is unrelated and the fix is over here: sigstore/scaffolding#277

@dlorenc
Copy link
Member

dlorenc commented Aug 9, 2022

I'll merge while we wait for the fix.

@dlorenc dlorenc merged commit fdceee4 into sigstore:main Aug 9, 2022
@github-actions github-actions bot added this to the v1.11.0 milestone Aug 9, 2022
@wata727 wata727 deleted the verify_cert_chain_by_default branch August 10, 2022 11:59
@cpanato cpanato mentioned this pull request Aug 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants