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

[Takahiko Kawasaki]

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.

‌