Allow configurable signing algorithms

[ret2libc]

Description

@tetsuo-cpp filed similar issues under Cosign and Rekor. We 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). We 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 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 sigstore-go, 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.

[steiza]

Hello! I think this should be relatively straightforward as sigstore-go today just supports verification, not signing. We can add additional signing algorithm support as needed to things like pkg/verify/signature.go and pkg/root/trusted_root.go.

[woodruffw]

xref: sigstore/protobuf-specs#189 will ultimately standardize the full registry of signing algorithms, but doesn't block initial work here (since we know a couple of ECDSA variants that'll need verification support already).

[tetsuo-cpp]

One requirement of this work is that verifying clients will need to take information about what signing algorithm was used to generate the signature since we can no longer assume SHA-256.

I think that this information can be part of the Sigstore bundle's VerificationMaterials, but each client including sigstore-go will require a --signing-algorithm flag for the non-bundle verification path. In the bundle spec, it might make sense to make this field optional and have clients fallback to ECDSA-SHA256 to avoid breaking changes.

Does this seem reasonable to you: @steiza @haydentherapper?

[ret2libc]

{
  "mediaType": "application/vnd.dev.sigstore.bundle+json;version=0.2",
  "verificationMaterial": {
     ...
  },
  "messageSignature": {
    "messageDigest": {
      "algorithm": "SHA2_256",
      "digest": "Xd/81x5QNKXw3pdWCvhoA2H4aS7Yd9F8hxlfyUtUVwg="
    },
    "signature": "MEQCIEeH9Ktf5pkHgdksH7mJCm4Jl66LemacsZHQ0VLKpgPOAiBsSM+neKdZE3l3AhxII1RuQOSKEk+TZRCspMjhvPxB0g=="
  }
}

@tetsuo-cpp are you talking about the signature algorithm or the hash one? I think the hash algo is already included in messageDigest in the bundle file. For the signature algorithm, instead, you could probably already deduce it from the Public Key included in the certificate (which is in the bundle), however even adding a "SignatureAlgorithm" in the bundle might not be ideal?

I believe we want the signature algorithm to come from an external policy, because you can't trust the file itself. If I sign a file with ECDSA-SHA256 today and in ten years from now ECDSA-SHA256 is broken, you want to make sure that the signature are from e.g. ED25519 and not ECDSA-SHA256, even though the file says so.

[tetsuo-cpp]

@tetsuo-cpp are you talking about the signature algorithm or the hash one? I think the hash algo is already included in messageDigest in the bundle file.

I don't think we can use that because you can also get a DSSE envelope in the bundle. From the spec:

        oneof content {
                dev.sigstore.common.v1.MessageSignature message_signature = 3 [(google.api.field_behavior) = REQUIRED];
                // A DSSE envelope can contain arbitrary payloads.
                // Verifiers must verify that the payload type is a
                // supported and expected type. This is part of the DSSE
                // protocol which is defined here:
                // <https://github.com/secure-systems-lab/dsse/blob/master/protocol.md>
                io.intoto.Envelope dsse_envelope = 4 [(google.api.field_behavior) = REQUIRED];
        }

Since we need this information in both cases, I figured it made sense to add it into the bundle (and we should wire any code that uses the message digest algorithm, to refer to the signing algorithm instead). That has the side-effect of ensuring that the bundles don't refer to a signing/hash combination that isn't valid in the Sigstore registry.

I believe we want the signature algorithm to come from an external policy, because you can't trust the file itself. If I sign a file with ECDSA-SHA256 today and in ten years from now ECDSA-SHA256 is broken, you want to make sure that the signature are from e.g. ED25519 and not ECDSA-SHA256, even though the file says so.

To me, this is two separate things: knowing what the signature algorithm is and restricting what signature algorithms are allowed. I'm proposing that the bundle format will document what signing algorithm was used to produce the signature so that a client knows how to verify it. That leaves the door open for clients to toggle what signing algorithms are allowed so that you can restrict this similar to how we allow them to be restricted in Fulcio and Rekor via --client-signing-algorithms. What do you think?

[ret2libc]

cc @woodruffw I think similarly to rekor, we want to limit the flexibility to the regular "hashedrekord" types, which I'm not sure include dsse_envelope. If that's the case, for dsse_envelope case we can just assume the default is whatever is used right now, while the flexibility is allowed only in the case of message_signature.

[haydentherapper]

Can you use the envelope hash from the Rekor entry?