Algorithms for HTTP message signatures
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- cryptography, documentation, security
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.
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
algsignature 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
- Dominant language
- HTML
- Stars
- 4
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openid/fapi
-
component: FAPI 1: Advanced migrated-from-bitbucket priority: major type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
migrated-from-bitbucket priority: trivial type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
component: Certification component: FAPI2: Advanced Authorization
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
component: Certification component: FAPI2: Security Profile
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Similar issues
-
Platform Platform Reconnect Platform Virtual Map
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
hiero-ledger/hiero-consensus-node#27313 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
branch: 4.1 branch: master help wanted triaged: bug waiting-for: contributor response
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
chinabugotech/hutool#4326 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
w3c/vc-di-quantum-resistant#44 · 1 reaction ·