Sigstore 如何把签名与身份绑定

Sigstore 的 keyless 签名通过短期证书把临时公钥与经过 OIDC 认证的身份绑定，再用对应私钥签署制品。接收方不仅验证签名，还要确认身份和 OIDC 签发者符合自己的发布策略。keyless 表示减少长期签名密钥管理，并不表示没有密钥。

官方文档：https://docs.sigstore.dev/

用一个发布文件理解身份签名

假设团队发布一个 release-notes.txt，接收方希望确认文件由指定发布者签署，且签署后内容未被修改。这里用普通文件作为小案例，不涉及镜像仓库，也不把签名理解为代码安全审查。

先从官方安装文档准备 Cosign，再确定预期发布身份和身份提供方。它们应来自团队发布规则，而不是下载到什么证书就接受什么身份。以下命令是供读者执行的示例，不代表本文已在本机完成签署或认证。

建议先用公开的非敏感演示文件熟悉交互，再把同一套身份条件用于正式发布。文件名、bundle 名与发布编号一一对应，可以减少把旧签名配给新文件的失误。

证书连接的是身份与公钥

在基于身份的签署中，客户端生成临时密钥对，携带公钥与可验证的 OIDC 身份令牌向 Fulcio 请求证书。证书把公钥与认证身份联系起来；私钥由签署端使用，而不是交给证书服务代为签署。

身份可能表示个人，也可能表示自动化工作流。对接 CI 时，预期身份应与实际工作流的证书身份格式对应，不能把个人邮箱模板直接当作所有工作流通用配置。短期证书也不替代身份提供方的访问控制。

签署文件并保留 bundle

# 对准备好的公开演示文件签署，按提示完成身份认证
cosign sign-blob release-notes.txt --bundle release-notes.sigstore.json

官方文档推荐使用 bundle 保存验证材料，其中包含签名、证书以及透明日志相关证明。交付时将原始文件与对应 bundle 一起保存。bundle 不是原始制品的替代品，接收方仍需要被签署的那个文件。

执行前应了解公共实例的透明日志公开性，避免把不适合公开关联的身份或材料用于演示。认证令牌不要写进命令历史、文章或发布日志。这里不使用自动确认参数，便于首次操作时阅读提示。

签署完成后不要再修改文件字节，包括换行和编码。需要更新内容时重新签署，并保存新的发布记录；不要仅重命名旧 bundle 冒充新版本材料。

验证时同时约束身份与签发者

# 两个示例值必须替换为预先确定的真实发布身份与 OIDC 签发者
cosign verify-blob release-notes.txt \
  --bundle release-notes.sigstore.json \
  --certificate-identity='publisher@example.com' \
  --certificate-oidc-issuer='https://accounts.example.com'

上面的邮箱和域名是占位值，不是可直接登录的配置。不要为了让任意证书通过而放宽身份匹配。若发布者变更，应通过团队认可的渠道更新策略，并保存变更依据。

判断失败原因时，区分文件内容不匹配、身份不匹配、issuer 不匹配，以及证书或日志证明相关错误。前者应核对制品与 bundle 的对应关系；身份类错误应回到发布策略。不要通过关闭关键验证来掩盖输入或身份配置错误。

把身份规则接入发布流程

接入流水线时，把验证命令的成功作为后续使用制品的前提。失败应终止该次接收或部署，不要只把错误打印出来后继续执行。制品摘要、bundle、Cosign 版本与预期身份规则宜作为同一发布记录保存。

自动化签署还需要使用适合 CI 的身份获取机制；本地登录的交互体验不能直接复制为无人值守任务。团队应明确哪些仓库、工作流和发布条件获得授权，并限制身份凭据的使用范围。这些属于发布策略，Sigstore 的密码学绑定不会替团队自动决定。

签名成功就说明软件安全吗？

不说明。签名帮助判断来源和完整性，漏洞分析、构建隔离与业务授权仍需各自处理。

证书过期后，旧发布一定无法验证吗？

不能只按当前时间作此结论。验证还涉及签署时刻及日志等材料，应由支持相应格式的工具按完整规则判断，保留 bundle 很重要。

能只验证签名、不限定发布者吗？

这无法回答“是否由预期发布者签署”。身份绑定的使用价值在于验证端明确预期身份及签发者。

签署参考：https://docs.sigstore.dev/cosign/signing/signing_with_blobs/

验证参考：https://docs.sigstore.dev/cosign/verifying/verify/