sigstore / cosign

Code signing and transparency for containers and binaries
Apache License 2.0
4.38k stars 537 forks source link

Allow configurable signing algorithms #3271

Open tetsuo-cpp opened 11 months ago

tetsuo-cpp commented 11 months ago

Description

I've filed similar issues under Cosign and Rekor. I realise there's a lot of overlap in maintainers, but wanted to make sure that we discuss each project that we plan to touch. Apologies if this feels a bit spammy.

Hi there! At Trail of Bits, we're looking at potentially implementing part of the Configurable Crypto Algorithms proposal (specifically Phase 1). I wanted to float this idea to each of the relevant Sigstore sub-projects so we can hash out the details in a more concrete way.

Across the Sigstore stack, we default to using ECDSA for signatures and SHA256 for hashing. There's more detail in the linked proposal but there are a number of motivations for wanting to customise the signatures that are generated, including paving the way for post-quantum signatures. The proposed design includes having a "supported algorithm" registry (perhaps this can go in the Protobuf specs) that outlines enumerates the approved signature/hash algorithm combinations. We specifically don't want to allow arbitrary mixing and matching of signature and hash algorithm to avoid some of the security pitfalls listed in the proposal.

For Cosign, we want to support this set of approved signing algorithms. This can be as simple as a --signing-algorithm flag. As a first pass, we'd like to support ECDSA with SHA256 and SHA384 as well as EdDSA, with ECDSA-SHA256 remaining as the default.

I believe that in order to change this, we may have to make changes to the sigstore-go and sigstore libs, but I figured that I'd make the issue here since cosign is going to be entrypoint for this functionality.

ret2libc commented 11 months ago

Some notes. ECDSA is assumed in the following places:

dlorenc commented 11 months ago

This is awesome!

haydentherapper commented 11 months ago

For the public instance, the TUF root keys will need to be rotated to PQ keys and the metadata will also need to be re-signed. We also have online KMS keys that sign the snapshot and target metadata that will either need to be rotated to PQ KMS keys (once that's supported). Note that the TUF reference implementation only mentions RSA, ECDSA and ed25519 (https://theupdateframework.github.io/specification/latest/#keytype) so that should be updated too.