verify: Support custom TUF mirror for private Sigstore trust root distribution

[sonupreetam]

Summary

---

🦾 Written with LLM assistance [claude-opus-4-6]
💪 Reviewed by a human before submission

---

Support a custom TUF mirror URL in VerificationConfig as the strategic alternative to filesystem-based trusted_root for enterprises needing the strongest chain-of-trust guarantees.

Context

PR #788 introduced trusted_root support for private Sigstore instances via a local file path. The threat model (THR02.MIT05) acknowledges that this file has no TUF integrity protection. While #798 proposes digest pinning as a near-term mitigation, a custom TUF mirror eliminates the entire class of filesystem substitution attacks by preserving the TUF verification chain.

Proposed Design

verification:
  issuer: https://dex.internal
  identity: signer@internal
  tuf_mirror: https://tuf.internal/
  tuf_root: <base64-encoded initial root.json>

The vendored sigstore-go/pkg/tuf/options.go already exposes WithRepositoryBaseURL(url) and WithRoot(rootBytes) on tuf.DefaultOptions(). The existing NewKeylessVerifier uses this API for the public Sigstore instance -- extending it to a custom mirror requires no new dependencies.

Security Properties

TUF provides protections that filesystem-based trust cannot:

• Threshold signing -- compromise of a single key is insufficient
• Root key rotation -- safe rollover without service interruption
• Freeze attack protection -- stale metadata is detected and rejected
• Rollback detection -- prevents serving older, vulnerable trust material

Implementation Notes

• tuf_mirror + tuf_root should be mutually exclusive with trusted_root (both configure the trust anchor, via different mechanisms)
• tuf_root (initial root.json) is a one-time provisioning step, not an ongoing file to protect
• The initial root.json can be distributed via secure channels (e.g., embedded in a container image, delivered via internal PKI)
• Consider caching the TUF state locally under XDG cache to avoid re-fetching on every invocation

Tradeoffs

• Operators must run a TUF repository (e.g., go-tuf CLI, TUF-on-CI, or a hosted solution)
• Higher infrastructure burden than file-based trusted_root
• Appropriate for enterprises with existing PKI/signing infrastructure; overkill for small teams

Related

• Parent: verify: Add trusted_root support for private Sigstore instance verification #768 (trusted_root support)
• PR: feat(verify): add trusted_root support for private Sigstore instances #788 (implementation of verify: Add trusted_root support for private Sigstore instance verification #768)
• Near-term mitigation: verify: Add digest pinning for custom trusted_root files #798 (digest pinning for trusted_root files)