Inconsistency in test vector generation (signing) and verification

[dahlia]

I've encountered a bug where test vectors generated by httpsig.org fail verification on the same site. This suggests an inconsistency between the signature generation and verification implementations.

Steps to reproduce

1. Generated a test vector on httpsig.org using the rsa-v1_5-sha256 algorithm
2. Attempted to verify the same signature on httpsig.org
3. Verification failed despite using the same test vector generated by the site

httpsig.org.mp4

Expected behavior

The signature verification should succeed when using test vectors generated by the same implementation.

Technical details

• Signature algorithm used: rsa-v1_5-sha256
• No modifications were made to the test vector between generation and verification

Questions

1. Is there a known issue with the verification process for rsa-v1_5-sha256 signatures?
2. Could there be a mismatch between the implementation of signature generation and verification components?
3. Are there any specific parameters or headers that need to be maintained exactly between generation and verification?

---

Thank you for your time. I'm available to provide any additional information that might help diagnose this issue.

[jricher]

Thank you for submitting such a thorough report, the video was very helpful. As far as I am aware, it was working previously, and the site has been put through its paces with a lot of testing so this is strange behavior to see pop up now, years later.

I have just gone through this is a bug in the validator here - specifically, the order of the parameters on the signature input to the validator are not respected during the parsing step. If you look closely at your signature base strings, the input has created then keyId, while the validator's base string has keyId and then created. Clearly the validator needs to remember and keep the order of the parameters as set by the signature input field value when it re-creates the base string, and so I don't know why it's acting weird like that. At first glance, I'm guessing this is a problem in the front end that puts the parameters together to feed into the verifier, but it could be something in the back end making an assumption it shouldn't.

Additionally, even when I fix the order here, it still isn't validating for RSA keys. I at first thought it was a problem with the key parser, since you pasted in the full public/private key pair instead of just the public key, but even cutting the JWK down to only the public key did not fix the behavior. This speaks to some other underlying issue.

Thanks for finding this, I'm going to dig into this now and we'll get it fixed!