[Openid-specs-fapi] Issue #718: "signature"; req and "signature-input"; req are not recommended (openid/fapi)

[Anders Rundgren]

On 2024-09-20 19:23, Takahiko Kawasaki via Openid-specs-fapi wrote:
> New issue 718: "signature";req and "signature-input";req are not recommended
> https://bitbucket.org/openid/fapi/issues/718/signature-req-and-signature-input-req-are
> 
> Takahiko Kawasaki:
> 
> [FAPI 2.0 Message Signing](https://openid.bitbucket.io/fapi/fapi-2_0-message-signing.html), [Section 5.6.2.1. Resource servers](https://openid.bitbucket.io/fapi/fapi-2_0-message-signing.html#section-5.6.2.1), the third clause says as follows:
> 
>> if the request was signed, shall include the request signature and request signature input in the response signature input by means of the `req` boolean flag defined in Section 2.4 of \[[RFC9421](https://openid.bitbucket.io/fapi/fapi-2_0-message-signing.html#RFC9421)\];
> 
> If this clause means that `"signature";req` and `"signature-input";req` must be included in the signature base \(and there seems to be no other way to interpret it\), then this clause should be removed.
> 
> The third-to-last paragraph of [Section 2.4. Signing Request Components in a Response Message](https://www.rfc-editor.org/rfc/rfc9421.html#section-2.4) in [RFC 9421 HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421.html) states the following and explicitly says it is “NOT RECOMMENDED” to do so for security reasons.
> 
>> While it is syntactically possible to include the Signature and Signature-Input fields of the request message in the signature components of a response to a message using this mechanism, this practice is **NOT RECOMMENDED**. This is because signatures of signatures do not provide transitive coverage of covered components as one might expect, and the practice is susceptible to several attacks as discussed in [Section 7.3.7](https://www.rfc-editor.org/rfc/rfc9421.html#security-sign-signature). An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely.

This is one of the reasons why I do not consider RFC 9421 as a viable solution for my take on the EU Payment Wallet.
There's no need putting signature values in HTTP headers when using deterministic CBOR:
https://github.com/cyberphone/cbor-everywhere?tab=readme-ov-file#signed-http-requests

Anders

> 
> ‌
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-fapi