feat: vsa support - Githubissues

ramonpetgrave64 commented 2 weeks ago

Fixes #542

Adds support for VSAs.

Testing process

added some unit an end-to-end tests

manually invoking

go run ./cli/slsa-verifier/ verify-vsa \
--subject-digest gce_image_id:8970095005306000053 \
--attestation-path ./cli/slsa-verifier/testdata/vsa/gce/v1/gke-gce-pre.bcid-vsa.jsonl \
--verifier-id https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
--resource-uri gce_image://gke-node-images:gke-12615-gke1418000-cos-101-17162-463-29-c-cgpv1-pre \
--verified-level BCID_L1 \
--verified-level SLSA_BUILD_LEVEL_2 \
--public-key-path ./cli/slsa-verifier/testdata/vsa/gce/v1/vsa_signing_public_key.pem \
--public-key-id keystore://76574:prod:vsa_signing_public_key \
--print-attestation

{"_type":"https://in-toto.io/Statement/v1","predicateType":"https://slsa.dev/verification_summary/v1","predicate":{"timeVerified":"2024-06-12T07:24:34.351608Z","verifier":{"id":"https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1"},"verificationResult":"PASSED","verifiedLevels":["BCID_L1","SLSA_BUILD_LEVEL_2"],"resourceUri":"gce_image://gke-node-images:gke-12615-gke1418000-cos-101-17162-463-29-c-cgpv1-pre","policy":{"uri":"googlefile:/google_src/files/642513192/depot/google3/production/security/bcid/software/gce_image/gke/vm_images.sw_policy.textproto"}},"subject":[{"name":"_","digest":{"gce_image_id":"8970095005306000053"}}]}
Verifying VSA: PASSED

PASSED: SLSA verification passed

TODOS:

open issue on the in_toto attestations repo about the incorrect json fields for vsa 1.0

ramonpetgrave64 commented 2 weeks ago

@haydentherapper @laurentsimon

kaixu-google commented 1 week ago

Could you consider adding well-known public key pems for VSAs to the SLSA verifier, at least in the short term? There are a large number of clients needs to verify Google-issued VSAs so it'll be easier to update the public key in case Google does a key rotation. Longer term, we could consider how to integrate Google's public key pem into sigstore.

haydentherapper commented 1 week ago

@kaixu-google The public key doesn't necessarily have to be distributed through Sigstore, it could also be distributed through GCS, through a well known endpoint, etc. We don't want to block development of this feature on figuring out how best to support key rotation. If we were to include the keys and later remove them, this would be a breaking feature. Additionally it would mean that slsa-verifier releases are tied to the key - if the key is revoked, then we must cut a new slsa-verifier release and revoke all previous releases as well (which we have no mechanism to do so, and that would be very problematic for all users).

AdamZWu commented 1 week ago

Could you consider adding well-known public key pems for VSAs to the SLSA verifier, at least in the short term? There are a large number of clients needs to verify Google-issued VSAs so it'll be easier to update the public key in case Google does a key rotation. Longer term, we could consider how to integrate Google's public key pem into sigstore.

Agree with Kai that the slew of key related parameters may feel a bit overwhelming to the end users:

slsa-verifier verify-vsa \
...
--public-key-path ./cli/slsa-verifier/testdata/vsa/gce/v1/vsa_signing_public_key.pem \
--public-key-id keystore://76574:prod:vsa_signing_public_key \
--public-key-hash-algo SHA256 \

Ideally, there could be a "registry" that allows different organizations to register info that are needed to verify their signatures. And then the end user only needs to identify their trusted organization(s). Something like:

slsa-verifier verify-vsa \
...
--trusted_issuer "Google, LLC."

But that is probably more fitted as a separate UX improvement FR. :)

haydentherapper commented 1 week ago

public-key-hash-algo is optional and defaults to sha256 which is almost always the case (except for ecdsa-p521 and ed25519 keys) - we could also rename that to signing-hash-algo to signify that it's related to the signature, not the public key. WDYT @ramonpetgrave64?

Long-term, we were talking about a mechanism to retrieve keys from well-known endpoints such that rotation is abstracted away. Then public-key-path would be optional as well. A registry for a large entity would be tricky since it's likely there will be multiple keys within an organization, so I suspect public-key-id will always be necessary.

ramonpetgrave64 commented 1 week ago

public-key-hash-algo is optional and defaults to sha256 which is almost always the case (except for ecdsa-p521 and ed25519 keys) - we could also rename that to signing-hash-algo to signify that it's related to the signature, not the public key. WDYT @ramonpetgrave64?

Long-term, we were talking about a mechanism to retrieve keys from well-known endpoints such that rotation is abstracted away. Then public-key-path would be optional as well. A registry for a large entity would be tricky since it's likely there will be multiple keys within an organization, so I suspect public-key-id will always be necessary.

Yes, or even public-key-signing-hash-algo.

ramonpetgrave64 commented 1 week ago

@kaixu-google Since Google VSAs are not yet publicly available, I hope that the plan is that distribution of Google's VSAs will be equally convenient as distributing their Public Keys. If that will be the case, I think we should stick with not embedding the key, given the cons that @haydentherapper spoke of.

@AdamZWu Ideally, Google's public key could be distributed and rotated within a Sigstore TUF Rooot, similar to how Npmjs distributes their signing keys.

ref: https://github.com/slsa-framework/slsa-verifier/pull/731/files#diff-e838304ec724aef1ba7a4db69d32ff0e02fcf541a96136f9790253c628b589f0R55-R57

ramonpetgrave64 commented 1 week ago

Thanks everyone for the first passes! I think we're ready for review.

kaixu-google commented 1 week ago

Thank you Hayden and Ramon! LGTM. I will try to file a FR to consider how to improve the UX.

-- Best, Kai Xu

On Tue, Jun 25, 2024 at 7:58 PM Ramon Petgrave @.***> wrote:

Thanks everyone for the first passes! I think we're ready for review.

— Reply to this email directly, view it on GitHub https://github.com/slsa-framework/slsa-verifier/pull/777#issuecomment-2190226157, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJNUY47W33UKU5X644OVCSLZJH74BAVCNFSM6AAAAABJUVOGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGIZDMMJVG4 . You are receiving this because you were mentioned.Message ID: @.***>

kaixu-google commented 1 week ago

LGTM.

-- Best, Kai Xu

On Wed, Jun 26, 2024 at 10:56 AM Ramon Petgrave @.***> wrote:

@kaixu-google https://github.com/kaixu-google

— Reply to this email directly, view it on GitHub https://github.com/slsa-framework/slsa-verifier/pull/777#issuecomment-2191921204, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJNUY46DWIXVXROLBQUMNNDZJLJBDAVCNFSM6AAAAABJUVOGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJRHEZDCMRQGQ . You are receiving this because you were mentioned.Message ID: @.***>

ramonpetgrave64 commented 6 days ago

@laurentsimon @ianlewis

slsa-framework / slsa-verifier

feat: vsa support #777

Testing process