Correctly determine derived component `@authority`

[oneiros]

This has been a wild day of chasing down rabbit holes (RSA, OpenSSL, different RFCs etc.) and my head is spinning. So forgive me if my interpretation of this is totally wrong:

I tried to write a test case (loosely) based on the example in this section here: https://www.rfc-editor.org/rfc/rfc9421.html#name-multiple-signatures

In that example the @authority component is derived from the host header as far as I understand. But there is also a forwarded header in the example. linzer delegates getting the @authority derived component to rack and rack uses the forwarded header to overwrite whatever is in host.

As a result linzer produces a different signature base than the example shows.

The question now is, did I do/get something wrong (totally possible 😅 ), is this a bug in linzer, is it a bug in rack or even a mistake in the RFC (I think I found another one, so again, quite possible)?

[nomadium]

A priori I'm inclined to think this is probably a bug in Linzer since I worked so far mostly on messages with 1 signature.

Also that example is using the alg="rsa-v1_5-sha256" that is one still pending for support since I didn't figure out the right options to use with OpenSSL as you mentioned...😵‍💫Could be a good time to finally get that done but I think I'll investigate first the possible issue with @authority component.

I'm going to spend some time tomorrow to figure out what could be wrong with @authority derived component in that scenario.

Interesting, what other mistake did you find in the RFC?

[oneiros]

A priori I'm inclined to think this is probably a bug in Linzer since I worked so far mostly on messages with 1 signature.

The fact that the example uses multiple signatures does not really matter for the problem at hand.

Also that example is using the alg="rsa-v1_5-sha256" that is one still pending for support

This is actually what I was working on, and this example is the only one in the RFC that uses this signature scheme, so I thought it would make sense to use it to validate the implementation.

PR is incoming.

Interesting, what other mistake did you find in the RFC?

It is an inconsistency with the test-key-rsa-pss example key. This example gives both a public and a private key in PEM format. The private key uses an oid of RSASSA-PSS, which makes sense to me. But the public key uses an oid of rsaEncryption. This might not be technically wrong (as I understand it, they are both RSA keys, PSS is just the signature scheme and can be used with both types of keys) but it is at least inconsistent and to be honest quite inconvenient.

[nomadium]

Now that you mention that inconsistency, that could explain the issues that I'm seeing with rsa-pss-sha512 algorithm. I strongly suspect is not implemented correctly as my unit tests pass with the keys and examples provided in the RFC but then if I go and I generate new key pairs, sign a message with them, the signature cannot be verified successfully.

Thanks for the PR implementing support for rsa-v1_5-sha256, it's very much appreciated and I'll take a look at it shortly.

[oneiros]

Now that you mention that inconsistency, that could explain the issues that I'm seeing with rsa-pss-sha512 algorithm. I strongly suspect is not implemented correctly as my unit tests pass with the keys and examples provided in the RFC but then if I go and I generate new key pairs, sign a message with them, the signature cannot be verified successfully.

Yes, exactly! I tried to explain this in more detail in #10

[nomadium]

👋 Hi @oneiros! I just opened a PR that maybe it could make sense for you to take a look. I was addressing a workaround that you needed to introduce to fix a buggy behaviour in Rack::Request regarding derived component @authority.

#15