Keyless threshold code signing

Mode 4 (Keyless Threshold) generalizes the Sigstore keyless pattern to threshold signing. For code signing, it replaces the traditional model — one maintainer holds one long-lived signing certificate — with a model where multiple maintainers authenticate via OIDC and jointly produce one release signature.

What changes for the verifier

Nothing. The verifier still sees:

  • One signature (64-byte (r, s) ECDSA-P256).
  • One public key (33-byte SEC1 compressed P-256 point).
  • One certificate (the Fulcio-issued short-lived cert that binds the OIDC identities to the joint public key).

The signature verifies under the public key in the normal way (OpenSSL, node:crypto, Go’s crypto/ecdsa, etc.). What’s different is where the public key came from: a per-ceremony threshold DKG, not a long-lived HSM.

What changes for the signers

Under the old model:

  • One maintainer holds a long-lived signing key.
  • That key signs every release.
  • If the key is lost, every future release is delayed until re-provisioning.
  • If the key is stolen, every past release is suspect until revocation propagates.

Under Mode 4:

  • N maintainers each authenticate via OIDC (GitHub Actions, Google, Okta) at signing time.
  • The coordinator runs ephemeral DKG across their ephemeral public keys → produces one joint ephemeral public key.
  • A Fulcio-style CA issues a short-lived cert binding the OIDC identities to the joint key.
  • T-of-N maintainers threshold-sign the release.
  • All ephemeral keys are destroyed at end of ceremony.

No long-lived key. No key storage. No key rotation. No HSM.

What ships with the release artifact

The release artifact ships with three things:

  1. The signature (standard ECDSA-P256 (r, s)).
  2. The Fulcio cert (X.509 DER, validity ~10 minutes).
  3. The transparency log entry (inclusion proof + tree head from log.confium.org).

The verifier checks all three:

verify signature against cert's public key
↓ OK
verify cert against Fulcio's root
↓ OK
verify inclusion proof against log.confium.org's tree head
↓ OK
→ release is authentic

If any step fails, the release is rejected.

Why threshold on top of keyless

Sigstore’s keyless model is single-party: one OIDC-authenticated identity signs. That’s perfect for individual developer commits. For releases — where many people rely on the artifact — single-party isn’t enough:

  • A compromised GitHub Actions runner can produce a “valid” keyless signature with whatever OIDC identity the runner has.
  • A single maintainer’s compromised OIDC session can sign malicious releases.

Mode 4 requires T-of-N OIDC-authenticated maintainers to participate. A single compromised identity cannot ship a release. The release signature proves a quorum of known maintainers agreed.

Example release pipeline

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: make dist

      - name: Threshold-sign release (Mode 4)
        env:
          OIDC_TOKEN: ${{ secrets.GITHUB_OIDC_TOKEN }}
          COORDINATOR_URL: tcp://coordinator.confium-internal:7443
        run: |
          # Each maintainer's CI job contributes their ephemeral
          # share. Coordinator waits for T-of-N, then assembles.
          confium mode4 sign \
            --coordinator "$COORDINATOR_URL" \
            --oidc-token "$OIDC_TOKEN" \
            --threshold 3 \
            --artifact dist/release.tar.gz

      - name: Publish
        run: |
          # Release now has: signature + Fulcio cert + log entry.
          gh release create "$GITHUB_REF_NAME" dist/release.tar.gz \
            --notes "Threshold-signed by Mode 4 ceremony"

Three maintainers’ CI jobs each contribute. The coordinator assembles when the third contribution lands. The release ships with a threshold-signed signature bound to the three maintainers’ OIDC identities.

When to use Mode 4 vs Modes 1–3

Need Mode
Daily release pipeline, no key management Mode 4
Long-lived CA key, institutional PKI Mode 3
Drop-in for existing HSM/PKI infrastructure Mode 2
Peer-to-peer threshold signing, no PKI Mode 1
Long-term archival (>10 years) Mode 3
Multi-jurisdiction sovereignty Mode 3

See also