Prerequisites

• I searched existing issues

Feature Summary

Add a standalone aicr evidence publish (sign + push + write pointer) that operates on an already-emitted on-disk evidence bundle, so the cluster-bound validation step and the Fulcio/Rekor-bound signing step can run on different networks.

Problem/Use Case

Validation must run where the cluster is reachable (often a corporate VPN), but keyless signing must reach fulcio.sigstore.dev + rekor.sigstore.dev, which corporate networks frequently block. Today aicr validate --emit-attestation --push does validate → emit → sign → push → write pointer.yaml as one atomic step, so if Fulcio is unreachable the whole publish fails (POST fulcio.sigstore.dev/api/v2/signingCert: EOF, exit 6) even though validation, OCI push, and OIDC all succeeded.

Proposed Solution

aicr evidence publish <bundle-dir> --push <ref> [signing/OIDC flags] that reuses the existing sign+push leg (today embedded in the validate emit path) against a pre-built summary-bundle/: package as OCI, keyless-sign the in-toto statement, attach the Sigstore referrer, write pointer.yaml. It signs the bundle bytes as-is (the timestamp is already baked at emit time → no determinism concern). validate --emit-attestation (no --push) remains the "produce unsigned bundle" step.

Success Criteria

• validate --emit-attestation <dir> on VPN → unsigned bundle; evidence publish <dir> --push <ref> off-VPN → signed artifact + pointer.yaml, identical to today's one-shot output.
• evidence verify on the resulting pointer/OCI hits signature-verify | passed.
• One-shot validate --emit-attestation --push behavior is unchanged (no breaking change).
• All signing/OIDC flags (--identity-token, --oidc-device-flow, --insecure-tls) are available on the new command.

Alternatives Considered

• Run the whole validate from a hotspot/off-VPN network — requires the cluster to be reachable from there, which it usually isn't.
• IT allowlist for *.sigstore.dev.
• KMS-backed signing (feat(bundle): KMS-backed signing for CI/CD environments without OIDC #407) — different mechanism, and still couples signing into the validate run.

Component

CLI (aicr)

Priority

Important (would improve my workflow)

Compatibility / Breaking Changes

None — additive. The new subcommand reuses the existing sign+push leg; the one-shot validate --emit-attestation --push path is untouched.

Operational Considerations

Decoupling lets the passing validation result be preserved as an artifact and signed/published from a host with Sigstore egress (CI runner, jump box, hotspot). The on-disk bundle is content-addressable, so the signed artifact is identical regardless of which step happened where.

Are you willing to contribute?

Maybe, with guidance