You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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!
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)
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.
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:
sigstore-go
verification flowscosign
sign/verify flowsThe 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
The text was updated successfully, but these errors were encountered: