add blog post on a SigstoreCon talk: Understanding the Identity of a CI Platform #71
Conversation
richardfan1126
force-pushed
the
understanding-the-identity-of-a-ci-platform
branch
from
990ce43 to
77ce84f
Compare
Signed-off-by: Richard Fan <[email protected]>
richardfan1126
force-pushed
the
understanding-the-identity-of-a-ci-platform
branch
from
77ce84f to
1f9b0cb
Compare
|
cc @sigstore/core-team please review |
|
|
||
| When verifying a sigstore keyless signature, solely relying on the Subject Alternative Name (SAN) is sometimes unreliable, especially when the signature is generated by a CI platform. This post talks about a [security research] where [GitHub reusable workflow](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) can be misused to generate signatures bearing SANs of another entity. | ||
|
|
||
| Verifying additional [Fulcio certificate extensions](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md) (e.g., Source Repository URI) is a way to ensure the real source of a CI-generated signature, but supports from different sigstore clients are not unified. sigstore users, both software maintainers and users, need to pay attention to using Fulcio certificates to verify software sources. |
There was a problem hiding this comment.
Can you point out where we have inconsistencies across Sigstore clients? I'd like to fix the bugs here too :)
There was a problem hiding this comment.
Thanks for reviewing my post.
The inconsistencies I observed are basically 2 things:
-
The support of OID extension verification
As the table at the end shows, not all clients support verifying the signature against OID extension. Some are partially supported only for GitHub signature.
This is not a problem because there are different timelines on each client dev teams and we shouldn't expect all client support everything on the first day.
However, I raise this situation on the post so users won't start implementing their software using one client, and then find out it doesn't support this feature. -
(This is a little bit technical, so I didn't mention in the post) The verification logic among 3 clients with full support (
sigstore-java,sigstore-python (API),sigstore-go) are different- First,
sigstore-javaonly provides low-level APIs for user to verify extension, it's the user's responsibility to know what the extension number, and data format the value are. - For
sigstore-pythonandsigstore-go, they provide the enums (Ref.1, Ref. 2) for user to specify their extension match requirements. But when interpreting those extensions, they have different logics on some fieldsIssuerV2:sigstore-pythonseparateIssuerandIssuerV2and exposes both fields for user to specify the matching requirement (asOIDCIssuerandOIDCIssuerV2class). (Ref)
Butsigstore-gomerge them into a single objectIssuer. Also, the parsing logic on whetherIssuerorIssuerV2is being used for matching is non-deterministic (Ref. 1, Ref.2). So as a user, I'm not sure which field is being matched against.OtherName SAN:sigstore-pythonextract this field and add it to the SAN list for the matching logic, butsigstore-goseems only allowing one SAN to be verified (Ref)
- First,
Summary
This PR adds a blog post on my SigstoreCon talk: Understanding the Identity of a CI Platform
Release Note
Documentation