[META] Cryptographic agility for Sigstore clients and services

[woodruffw]

Hi everyone! I figure most people are aware of aspects of this work, but I'm filing a meta-issue as a permanent record with (hopefully) enough details to fill everything in 🙂

TL;DR: My colleagues and I (at @trailofbits) are currently working on a handful of different features/changes to the (Go) clients and services (i.e. Rekor & Fulcio) to enable cryptographic agility across an agreed-upon common suite of algorithms. The ultimate vision for this is enabling a post-quantum (PQ) posture for the Sigstore ecosystem. The current plan is to prove out our approach to agility with a non-PQ addition (namely Ed25519{,ph}), with the plan to add a PQ suite once we have suitable assigned numbers (IANA or otherwise).

Here's what we have currently planned, and are currently working on:

• Completing the design and implementation of an "algorithm registry" API
  • Create Algorithm Registry API sigstore#1601
• Support for configurable algorithms in Fulcio
  • Allow configurable client signing algorithms fulcio#1517
• Support for configurable algorithms in Rekor
  • http://github.com/sigstore/rekor/pull/1724
• Allowing configurable algorithms during sigstore-go verification flows
  • Allow configurable algorithms in verification sigstore-go#76
• Adding support for Ed25519ph to cosign sign/verify flows
  • Add support for ED25519ph for sign/verify(-blob) commands cosign#3479

The above is listed in rough order of priority: our plan is to tackle shared components/APIs first (e.g. sigstore/sigstore), followed by services, followed by Go clients. As always, we eagerly welcome any feedback or thoughts on this approach!

cc for viz: @cmurphy @bobcallaway @codysoyland @haydentherapper @loosebazooka @steiza

[bobcallaway]

@sigstore/core-team FYI

[jku]

For completeness:

• TUF clients and root-signing are cryptographically agile already, at least in theory. In practice this depends on what the used hardware keys and KMSs support (just like with many things on the above list)

[trishankatdatadog]

• TUF clients and root-signing are cryptographically agile already, at least in theory. In practice this depends on what the used hardware keys and KMSs support (just like with many things on the above list)

Precisely. Also, I think we should be able to easily reuse the Sigstore Trusted Root here to upgrade/deprecate/remove which algorithms are supported over time.

[ret2libc]

Support for configurable algorithms in Fulcio

• Allow configurable client signing algorithms fulcio#1517

This was done in sigstore/fulcio#1938

Allowing configurable algorithms during sigstore-go verification flows

• Allow configurable algorithms in verification sigstore-go#76

This was done in sigstore/sigstore-go#424

Adding support for Ed25519ph to cosign sign/verify flows

• Add support for ED25519ph for sign/verify(-blob) commands cosign#3479

This is being done in sigstore/cosign#4050 and sigstore/cosign#3497 .