Verify who signed what under an explicit trust policy

Use the signature scheme's defined verification procedure on the exact signed representation; signatures are not universally explained as decrypting a hash. For an image signature, check that the verified claims identify the intended artifact digest rather than a different release. A valid signature on unrelated bytes is irrelevant. When using a certificate-based workflow, validate the chain to approved roots and the expected identity and issuer constraints. Sigstore's documented Cosign identity-based examples specify both identity and OIDC issuer. Accepting any identity certified by a broad ecosystem is different from approving your release workflow.

Keep verification and authorization results explicit. Cryptographic success means the signature is consistent with the verified payload and key under the algorithm's assumptions. Identity validation associates that key with an asserted identity under the certificate system. Authorization decides whether that identity may make this claim about this artifact for this deployment. A stolen credential or compromised approved workflow can produce signatures that pass the first checks. Review what the identity is allowed to assert and retain source, builder, and policy context rather than converting every verified signature into a universal safe label.

Short-lived signing certificates create an important distinction between the verifier's current time and the time relevant to the signature. An expired certificate does not automatically prove every historical signature invalid, nor does a timestamp typed into the signed payload establish when signing occurred. A verification bundle can carry certificates, signatures, and transparency or timestamp material that the verifier checks under the applicable format and policy. The trusted time and log requirements depend on that workflow. Do not bypass chain or time checks merely because an artifact was previously accepted on another machine.

Root and key rotation must update verifier trust through an authenticated mechanism, with versions, validity, and rollback protections appropriate to the system. Sigstore's trust model describes maintaining trust material through TUF; fetching arbitrary replacement roots from the artifact's registry is not equivalent. Plan overlap and retirement deliberately so old releases are handled according to policy while compromised authorities can be restricted. A key's removal from future signing and an artifact's revocation from deployment are different actions. Record which trust version supported a decision so an incident can identify stale acceptance caches and offline verifiers.

Some organizations require several distinct approvers for a release. Count only signatures that verify, bind the intended subject, and satisfy the approval policy; repeated signatures from one identity do not create independent authorities. Threshold design must account for shared credentials and administrative control rather than assume different key names imply independence. Document exceptional recovery and trust-update procedures before an outage. The example here uses a fictional three-of-five approval rule; it is not a statement that Sigstore or every signature format implements that particular threshold rule.

The reliability lab can display the count arithmetic alone. For each separate run, Reset, set both replica count n=5 and unavailable count k, predict the remaining count and majority indicator, then inspect. With k=2, three remain and meet the instrument's majority count; with k=3, two do not. This is a deterministic availability model, not a signature verifier, threshold-cryptography implementation, or estimate of independent signer compromise. In a real approval workflow, being online is insufficient: each counted signature must also pass content, identity, time, and authorization checks.