http-sig: Update http message signatures for OCM after spec review#62543
Open
mickenordin wants to merge 2 commits into
Open
http-sig: Update http message signatures for OCM after spec review#62543mickenordin wants to merge 2 commits into
mickenordin wants to merge 2 commits into
Conversation
mickenordin
requested review from
leftybournes,
provokateurin and
salmart-dev
and removed request for
a team
July 26, 2026 13:27
Implements the changes from cs3org/OCM-API#391 and closes the remaining gaps with the HTTP Message Signatures section: - discover peer JWK Sets via the new `jwksUri` discovery field instead of the fixed /.well-known/jwks.json path; advertise our own jwksUri and require it (https) from peers advertising the `http-sig` capability - stop covering the Date header; freshness is anchored on the `created` signature parameter - mark and select the OCM signature by its integrity-protected tag="ocm" parameter instead of the dictionary label - require the JWK `alg` parameter and derive the signature algorithm from it, accepting fully-specified RFC 9864 names - reject signed requests whose verification key cannot be resolved instead of treating them as unsigned - derive the signer origin from the spec-canonical fqdn#id keyid form Signed-off-by: Micke Nordin <kano@sunet.se>
The annotation was added as 34.0.0 in #60136, but stable34 branched before the PR merged, so the API first ships in 35. Signed-off-by: Micke Nordin <kano@sunet.se>
mickenordin
force-pushed
the
kano-update-httpsig
branch
from
July 26, 2026 13:29
b8eb0c3 to
97e3ba5
Compare
Contributor
|
Sorry, tapped the wrong button |
Member
Seems this is breaking HTTP (without S) which can be used in real world, but is especially used in all tests (also in other apps outside of server) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This pr adjust the format of HTTP Message Signatures following the review of OCM that resulted in some modifications to OCM spec: cs3org/OCM-API#391
tagrather than alabel. This is because a label is simply a key, where as the tag is signed.algparameter in the jwks.I also updated annotations
since, because the original httpsig PR was not merge before NC34 was released, so it needed some updates.Checklist
3. to review, feature component)stable32)AI (if applicable)
Manual testing:
This request:
Has the headers:
This is between two servers (alice and bob) that support the RFC9421 signatures.
Between a server that supports both, and a server with only draft-cavage support (alice and charlie) it looks like this for the body:
headers:
And for charlie to bob:
with headers:
Functionally the pr works, and is backwards compatible. It may break between servers running on an unpatched master and a patched master, but that is not a too big concern I think since the code it changes is not yet in any release.