HashedRekord Signer/Validator LoadOptions question

[ret2libc]

Question
As part of making the sigstore ecosystem crypto-agile, we (@trailofbits) have been making a few changes over the past ~year, see sigstore/sig-clients#16 .

Some of the changes that were done include 9865ca9 , 92742be , and faae13b .

One of the main changes to support ed25519ph was done in 92742be and it required passing a WithEd25519ph() option when creating the sigObj

92742be#diff-1211bf2bcbf1dac120447571e8a2d0940bb66a0b3c2554ecb040c54407c6173cR150

		return nil, nil, types.ValidationError(errors.New("missing signature"))
	}
	// Hashed rekord type only works for x509 signature types
-	sigObj, err := x509.NewSignature(bytes.NewReader(sig.Content))
+	sigObj, err := x509.NewSignatureWithOpts(bytes.NewReader(sig.Content), options.WithED25519ph())
	if err != nil {
		return nil, nil, types.ValidationError(err)
	}

However, this would not work if e.g. you want to use RSA PSS (which also require special LoadOption to be passed to the LoadSignerVerifier functions). For that to work, validate would have to know which LoadOptions to use, however that information cannot be determined from any of the available information and it would likely require a new version of the hashedrekord schema to include those options.

What are your thoughts on this?

cc @haydentherapper @bobcallaway

[haydentherapper]

I'm leaning towards accepting that we can't concurrently support RSA-PKCS1v1.5 and RSA-PSS. For hashedrekord, support ed25519ph has more meaningful value in that it unlocks using ed25519 whereas RSA-PSS isn't much more useful over the other RSA scheme.

The only other solution I could think of that I think we had discussed was creating multiple verifiers and trying to verify a signature with each but I don't love this approach, seems prone to error.

[ret2libc]

The only other solution I could think of that I think we had discussed was creating multiple verifiers and trying to verify a signature with each but I don't love this approach, seems prone to error.

I think we have discussed this on the cosign-side to maintain backward compatibility, where we sometimes verify with both pure-ed25519 and ed25519ph, but I agree doing this on rekor-side seems worse.

[haydentherapper]

Given the lack of RSA-PSS support throughout Sigstore clients as well, I think what we have now is sufficient. As we add more algorithms for PQC, I think we should avoid needing options, with each PQ key uniquely identifiable.