openid / openid/fapi

Algorithms for HTTP message signatures

Open
#710 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

component: HTTP Signing migrated-from-bitbucket priority: major type: proposal
Dominant language
HTML
Stars
3
Forks
3
PR merge metrics
No merged PRs in 30d

Description

Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2024-10-07

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), the verifier must be able to determine the algorithm for verification. Since JWTs always include the alg parameter (RFC 7518 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) in the signature metadata appears to be usable, but Section 3.3.7. JSON Web Signature (JWS) Algorithm 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 (Section 6.2), 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) 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 of the FAPI 2.0 Security Profile, 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.


Bitbucket status: open

Bitbucket origin: issue 722

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the FAPI 2.0 Message Signing specification alongside RFC 9421 and Section 5.4 of the FAPI 2.0 Security Profile. Determine whether JWK alg values should be mandatory and whether HTTP message signatures should use the listed algorithm restrictions; done means the specification records the decided requirements clearly.

Written by the indexing model from the issue text.

Assessment

Domain
cryptography, documentation, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.