OCP/Telco Definition of Done
Epic Template descriptions and documentation.

Epic Goal

• On top of sigstore support delivered in RHEL 8.7/9.1, enhance it to provide the important truly new features (Fulcio: OIDC integration for short-term certificates, and Rekor: uploads of signatures to a transparency log).
  • Note: Fulcio and Rekor servers are assumed to be run externally, providing or maintaining that software is not a part of this epic.
• Also follow up on tech debt from the RHEL 8.7/9.1 work.

Why is this important?

• Using OIDC authentication instead of maintaining per-user private keys potentially reduces the number of secrets that have to be managed, at the cost of probably reducing automation of signing.
• Uploading signatures to a transparency log, and enforcing transparency log presence when verifying signatures, could potentially (with a fair amount of infrastructure that seems not to exist) allow timely detection of unexpected rogue signatures after a successful credential/infrastructure compromise.
• Tech debt reduction allows us to sustainably support the already delivered features without unexpected regressions or surges in support costs.

Scenarios

1. Users can, instead of providing a private key, sign images by asking a Fulcio server to generate a short-term certificate, and authenticating to an OIDC server. The signature will be uploaded to a Rekor transparency log server.
2. Users can configure signature enforcement to accept Fulcio-issued certificates (for specified identities), and to require Rekor transparency log presence proofs.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Interactive users can sign using Fulcio-generated certificates, and upload signatures to Rekor.
• Non-interactive users have a way to use Fulcio+Rekor.
• policy.json can be configured to require Fulcio-generated-certificate signatures for a specific identity, with sufficient matching expressiveness.
• If policy.json is configured to require Fulcio, Rekor presence proofs are also required.
• Tech debt, as described in the relevant story, is handled.

Dependencies (internal and external)

1. Users are expected to provide running and configured Fulcio and Rekor servers, and an OIDC endpoint. Providing software, or a service, to run any of that, is out of scope.

Previous Work (Optional):

1. https://issues.redhat.com/browse/RUN-1533

Open questions::

1. A reasonable UI for using Fulcio + Rekor will probably require defining a file format to provide all the individual configuration items necessary (servers addresses + how to use an OIDC server)
2. It's not very clear how much can Fulcio + OIDC be used in completely non-interactive scenarios, or in very isolated containers. In the worst case, users can supply an existing ID token — then they will have to be provided software to obtain such tokens.

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>