[Openid-specs-fapi] Issue #722: Algorithms for HTTP message signatures (openid/fapi)

[Takahiko Kawasaki]

New issue 722: Algorithms for HTTP message signatures
https://bitbucket.org/openid/fapi/issues/722/algorithms-for-http-message-signatures

Takahiko Kawasaki:

There are two topics: one is how to identify the algorithm of a given HTTP message signature, and the other is whether to impose restrictions on the algorithms.

### How to identify the algorithm

Even if a key can be identified in a vendor-neutral manner by using the `keyid` parameter \([ISSUE 721](https://bitbucket.org/openid/fapi/issues/721)\), the verifier must be able to determine the algorithm for verification. Since JWTs always include the `alg` parameter \([RFC 7518 Section 3.1](https://www.rfc-editor.org/rfc/rfc7518.html#section-3.1)\), identifying the algorithm is straightforward. However, HTTP message signatures do not always provide information about the algorithm.

The `alg` parameter \([RFC 9421 Section 2.3](https://www.rfc-editor.org/rfc/rfc9421.html#section-2.3)\) in the signature metadata appears to be usable, but [Section 3.3.7. JSON Web Signature \(JWS\) Algorithm](https://www.rfc-editor.org/rfc/rfc9421.html#section-3.3.7) of RFC 9421 explicitly states the following:

> JSON Web Algorithm \(JWA\) values from the "JSON Web Signature and Encryption Algorithms" registry are not included as signature parameters. Typically, the JWS algorithm can be signaled using JSON Web Keys \(JWKs\) or other mechanisms common to JOSE implementations. In fact, JWA values are not registered in the ["HTTP Signature Algorithms" registry](https://www.rfc-editor.org/rfc/rfc9421.html#hsa-registry) \([Section 6.2](https://www.rfc-editor.org/rfc/rfc9421.html#hsa-registry)\), and so **the explicit** `alg` **signature parameter is not used at all when using JOSE signing algorithms.**

This excerpted paragraph above implies that, when the key is represented as a JWK,  the `alg` parameter \([RFC 7517 Section 4.4](https://www.rfc-editor.org/rfc/rfc7517.html#section-4.4)\) within the JWK should be referenced. However, the parameter is optional. Therefore, in practice, it is necessary to require the `alg` parameter within the JWK to be mandatory when the key is represented as a JWK. It may be worth mentioning this in the FAPI 2.0 Message Signing specification. Otherwise, client applications may register their public keys in JWK format without the `alg` parameter, leading to failed verification of HTTP message signatures. As a result, resource server providers will have to spend time instructing client application developers to include the `alg` parameter when registering JWKs.

### Whether to impose restrictons on the algorithm

It should be explicitly stated that the algorithms for HTTP message signatures are restricted to those listed in [Section 5.4. Cryptography and Secrets](https://openid.net/specs/fapi-2_0-security-profile.html#section-5.4) of the [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-2_0-security-profile.html), if we intend to apply the same restrictions to them.

This is a minor detail, but the FAPI 2.0 Security Profile states _“when creating or processing JWTs.”_ However, the format of HTTP message signatures is not JWT. Therefore, unless explicitly required, the algorithm restrictions stated in the FAPI 2.0 Security Profile do not apply to HTTP message signatures.

Of course, it is also possible to decide not to impose such restrictions on the signature algorithms for HTTP message signatures.

‌

‌

‌