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
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.
The text was updated successfully, but these errors were encountered:
Some notes. ECDSA is assumed in the following places:
cosign.GeneratePrivateKey, used from GenerateKeyPair(called when doing cosign generate-key-pair) and from signerFromNewKey (called when doing cosign sign-blob and generating an ephemeral key for getting the certificate)
cosign.ImportKeyPair handles only RSA, ECDSA, and ED25519 keys. This function is used in the cosign import-key-pair command
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.
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.The text was updated successfully, but these errors were encountered: