http-sig: Update http message signatures for OCM after spec review by mickenordin · Pull Request #62543 · nextcloud/server

mickenordin · 2026-07-26T13:27:40Z

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

Date is no longer signed, some intermediaries sometimes rewrite the date header, causing the signature to fail. Since we already sign created it is fine.
We switch to using an ocm tag rather than a label. This is because a label is simply a key, where as the tag is signed.
We add the jwksUri to the discovery, since RFC7517 does not in fact standardize .well-known/jwks.json. I left the actual endpoint there, but i can be moved in the future if we want, as long as the discovery is updated along with it.
Key algorithm discovery is done via the alg parameter in the jwks.
Require the keyid signature parameter.

I also updated annotations since, because the original httpsig PR was not merge before NC34 was released, so it needed some updates.

Checklist

Code is properly formatted
Sign-off message is added to all commits
Tests (unit, integration, api and/or acceptance) are included
Screenshots before/after for front-end changes
Documentation (manuals or wiki) has been updated or is not required
Backports requested where applicable (ex: critical bugfixes)
Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

The content of this PR was partly or fully generated using AI

Manual testing:

This request:

{
    "shareWith": "bob@https://bob.ocm.drive.test.sunet.se",
    "shareType": "user",
    "name": "2026-07-07T11:38:03,169846023+02:00.png",
    "resourceType": "file",
    "description": "",
    "providerId": "48",
    "owner": "alice@alice.ocm.drive.test.sunet.se",
    "ownerDisplayName": "alice",
    "sharedBy": "alice@alice.ocm.drive.test.sunet.se",
    "sharedByDisplayName": "alice",
    "sender": "alice@alice.ocm.drive.test.sunet.se",
    "senderDisplayName": "alice",
    "protocol": {
        "name": "webdav",
        "webdav": {
            "uri": "https://https://bob.ocm.drive.test.sunet.se/public.php/webdav/",
            "sharedSecret": "WB7i0NLgWFB6t2D65g7ATtW9QK1uwVRA",
            "permissions": [
                "{http://open-cloud-mesh.org/ns}share-permissions"
            ]
        }
    }
}

Has the headers:

POST https://bob.ocm.drive.test.sunet.se/index.php/ocm/shares HTTP/2.0
content-type: application/json
content-digest: sha-256=:ylqyzlJCuqc3YDhViVz61MWy6XGxYRDuSn4QfuMnc/Y=:
date: Sun, 26 Jul 2026 13:07:20 GMT
signature-input: ocm=("@method" "@target-uri" "content-digest" "content-length");created=1785071240;keyid="https://alice.ocm.drive.test.sunet.se/ocm#ecdsa-p256-sha256-1";tag="ocm"
signature: ocm=:H0JNrxoe6E61CKUtvbixpdzYdyr06sIpbS03H4ENtV7T5KblumxuZyvA5x4vSoMbcxugnX/8M2fiNKEmKeAAHg==:
user-agent: Nextcloud-Server-Crawler/35.0.0 dev
accept-encoding: br, gzip
content-length: 647

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:

{
    "shareWith": "charlie@https://charlie.ocm.drive.test.sunet.se",
    "shareType": "user",
    "name": "welcome.txt",
    "resourceType": "file",
    "description": "",
    "providerId": "49",
    "owner": "alice@alice.ocm.drive.test.sunet.se",
    "ownerDisplayName": "alice",
    "sharedBy": "alice@alice.ocm.drive.test.sunet.se",
    "sharedByDisplayName": "alice",
    "sender": "alice@alice.ocm.drive.test.sunet.se",
    "senderDisplayName": "alice",
    "protocol": {
        "name": "webdav",
        "options": {
            "sharedSecret": "UzJ7vrrKNycDa2fDlyOlFGWopsRnEPr8",
            "permissions": "{http://open-cloud-mesh.org/ns}share-permissions"
        }
    }
}

headers:

POST https://charlie.ocm.drive.test.sunet.se/ocm/shares HTTP/2.0
content-type: application/json
date: Sun, 26 Jul 2026 13:14:04 GMT
digest: SHA-512=QMy9wsI/MzJJ15HouiFG0VvdgjTkYl3GUAZ0k6ZGyA6RzgdI2v6i+IFHeNRj9BDpfxl5r40MgVXE5Ha5DwmrsA==
signature: keyId="https://alice.ocm.drive.test.sunet.se/ocm#signature",algorithm="rsa-sha512",headers="(request-target) content-length date digest host",signature="u0QffxZWI6mtXEQUyGrjoE0SZDzNO3YFhKyKq46ewsSFqpAtrZzSqhJUHeNU4dVjAC09umFrvY74XN9dif14bmaMf6ps9lF5VweE+LVAk/FS7BmbqJ5nSSkxyc2ZHwcoDH6GbLJk7vg4PMSWxZpJvyk67vZ+RwH58GLi1n/1Vqcl8XyCrgjYXNer+zHS5Fzzy4gllM0QsLglKsKfv0pf/sfpUXkO9wa2aDo0tbDCLql4EuvGC7lyg8Fbn0kgpjrezimtuvzPeZ0BE/I2RGr6vPfebA8Y9fhAn6Fuzge8pviDsoC+2wQJUrMx3ZdDXMRTm3RvsOMUtpLzA0L6UYDYjg=="
user-agent: Nextcloud-Server-Crawler/35.0.0 dev
accept-encoding: br, gzip
content-length: 548

And for charlie to bob:

{
    "shareWith": "bob@https://bob.ocm.drive.test.sunet.se",
    "shareType": "user",
    "name": "Readme.md",
    "resourceType": "file",
    "description": "",
    "providerId": "6",
    "owner": "charlie@charlie.ocm.drive.test.sunet.se",
    "ownerDisplayName": "charlie",
    "sharedBy": "charlie@charlie.ocm.drive.test.sunet.se",
    "sharedByDisplayName": "charlie",
    "sender": "charlie@charlie.ocm.drive.test.sunet.se",
    "senderDisplayName": "charlie",
    "protocol": {
        "name": "webdav",
        "options": {
            "sharedSecret": "FxnX4J6ZNMA3yUk",
            "permissions": "{http://open-cloud-mesh.org/ns}share-permissions"
        }
    }
}

with headers:

POST https://bob.ocm.drive.test.sunet.se/index.php/ocm/shares HTTP/2.0
content-type: application/json
date: Sun, 26 Jul 2026 13:17:21 GMT
digest: SHA-512=y5569iwDkc2FgiwPe/feC77ohzncy2NDpxcRAuZBjD2EETR7bH1l4EYtlCL7BxFiqE3q2gGVeuKaKWVqLVKTwQ==
signature: keyId="https://charlie.ocm.drive.test.sunet.se/ocm#signature",algorithm="rsa-sha512",headers="(request-target) content-length date digest host",signature="MgP+5oEV0+qAx1UiWWodQUSSkYDDyCgZJ+5EZPZOMtHj9c9TTR2xwbNuoWtzTf2TVq/HcQ9XZAS3TA6/ZF7DIhVG20/Em63UeTVNvUREojibxCRRB/IMBl5IUxve4swk7F1jnqUWINMi2MKd8igYdk1cESzLzQXC/GUL5CraYrKO1Ke8tG2MBzpjQWQ4o/53yjt93XKW+KC3dbx9LN5tq5U583z6RajwfdUt95uK0aRPDoJXRTU1satAryRRKmx0XYC7W/Aztpo6l6YEVAP0a33doEEDF6SpmwZHXJcoYM90AXcS/xxfY5YBudgUms2Alls8in0NXVFhn0EUR46a3A=="
user-agent: Nextcloud-Server-Crawler/33.0.3
accept-encoding: gzip
content-length: 538

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.

Antreesy · 2026-07-26T17:17:30Z

Sorry, tapped the wrong button

nickvergessen · 2026-07-26T20:11:58Z

Sharing textfile0.txt failed, could not find group1@http://localhost:8180, maybe the server is currently unreachable or uses a self-signed certificate.

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)

nickvergessen

Sharing textfile0.txt failed, could not find group1@http://localhost:8180, maybe the server is currently unreachable or uses a self-signed certificate.

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)

nickvergessen · 2026-07-28T07:12:20Z

Also fails Talk integration tests in test(server#62543): Test branch kano-update-httpsig spreed#18824
So this needs some analysis and explanation for why the ecosystem is being broken and needs adjustment

mickenordin · 2026-07-28T08:19:22Z

Also fails Talk integration tests in test(server#62543): Test branch kano-update-httpsig spreed#18824

So this needs some analysis and explanation for why the ecosystem is being broken and needs adjustment

It looks like the same https problem as mentioned above. I will push another commit to fix that, and I think the agreement is to allow http for serving your keys if necessary.

mickenordin · 2026-07-28T15:20:37Z

@nickvergessen can you rerun the talk test?

nickvergessen · 2026-07-28T19:42:35Z

Seems to be green now again, thanks for the adjustment

mickenordin · 2026-07-28T20:25:36Z

I found a bigger problem, the old code gets the identity of the calling server from the key id, and the new http-sig code did the same, but the keyid can be anything, it is an opaque identifier and we cant assume that it is a valid url. So now I am resolving the servers origin from the share or the notification instead. I will let the test suite run again, and run it once more through my manual testing to see that it is ok.

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>

The spec mandates https for jwksUri but allows an HTTP fallback in testing setups. Advertise the scheme the instance actually serves, and accept an http jwksUri only from a peer whose own endpoint is http: integration tests and http intranets work without configuration, while an https peer advertising an http jwksUri is still rejected, since that downgrade would let a path attacker swap the key material. An https jwksUri is always accepted, also from http-only peers, and it may live on a different host than the peer. Signed-off-by: Micke Nordin <kano@sunet.se>

The JWKS signing keyId was persisted as a full URL, frozen at whichever host provisioned the key first. An instance addressed by more than one host (the two-port integration rig, or a port change behind a proxy) then signed with a keyId whose host no longer matched its federated share identity, so receivers rejected the request with an origin mismatch. Persist only a stable opaque key id (ecdsa-p256-sha256-<n>) and rebuild the full keyId per request from the current URL, in both the signing signatory and the published JWK Set. The signature keyid and the JWKS kid still match, since both are built from the same opaque id and the current request host. Rotation still works: slots differ by the counter, and the host is just fresh context. Drops the resolveKidBase/canonicalKid hostname machinery and the ocm_jwks_kid_base appconfig, which are no longer needed. Assisted-by: ClaudeCode:glm-5.2 Signed-off-by: Micke Nordin <kano@sunet.se>

RFC 7517 §4.5 leaves the keyid structure unspecified, so the receiver must not parse it. The signer origin now comes from the trusted OCM share/sender identity; the JWK Set is resolved against that origin and the keyid is matched opaquely to the JWKS kid. Aligns with the OCM verification procedure and fixes the origin-mismatch / flaky-kid failures in the two-port integration rig. Reverts the per-request host-based kid back to a stable persisted kid, drops keyid->host parsing, threads a sender-origin parameter through verification, and resolves that origin in every OCM inbound entry point (notifications, shares, token exchange, OCM requests) and the federation rate limiter. Cavage is unchanged. Assisted-by: ClaudeCode:glm-5.2 Signed-off-by: Micke Nordin <kano@sunet.se>

mickenordin requested review from CarlSchwan and miaulalala July 26, 2026 13:27

mickenordin requested review from a team and nickvergessen as code owners July 26, 2026 13:27

mickenordin requested review from leftybournes, provokateurin and salmart-dev and removed request for a team July 26, 2026 13:27

mickenordin changed the title ~~Kano update httpsig~~ http-sig: Update http message signatures for OCM after spec review Jul 26, 2026

mickenordin force-pushed the kano-update-httpsig branch from b8eb0c3 to 97e3ba5 Compare July 26, 2026 13:29

mickenordin added 3. to review Waiting for reviews 35-feedback labels Jul 26, 2026

mickenordin added this to the Nextcloud 35 milestone Jul 26, 2026

mickenordin added AI assisted community pull requests from community labels Jul 26, 2026

Antreesy closed this Jul 26, 2026

Antreesy reopened this Jul 26, 2026

mickenordin mentioned this pull request Jul 26, 2026

Address reviewer feedback on httpsig cs3org/OCM-API#391

Merged

CarlSchwan approved these changes Jul 27, 2026

View reviewed changes

nickvergessen requested changes Jul 27, 2026

View reviewed changes

nickvergessen mentioned this pull request Jul 27, 2026

test(server#62543): Test branch kano-update-httpsig nextcloud/spreed#18824

Draft

3 tasks

mickenordin force-pushed the kano-update-httpsig branch 2 times, most recently from 750e748 to f94f587 Compare July 28, 2026 14:43

mickenordin force-pushed the kano-update-httpsig branch from f94f587 to 41b32a8 Compare July 28, 2026 16:39

mickenordin force-pushed the kano-update-httpsig branch from 41b32a8 to c0b1d0b Compare July 28, 2026 16:49

mickenordin added 4 commits July 28, 2026 22:25

fix(ocm): correct confirmRequestOrigin @SInCE to 35.0.0

519068a

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 5 times, most recently from 13cbd0a to 438674c Compare July 28, 2026 22:29

mickenordin force-pushed the kano-update-httpsig branch from 438674c to 6abbe1a Compare July 28, 2026 22:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

http-sig: Update http message signatures for OCM after spec review - #62543

http-sig: Update http message signatures for OCM after spec review#62543
mickenordin wants to merge 5 commits into
masterfrom
kano-update-httpsig

mickenordin commented Jul 26, 2026 •

edited

Loading

Uh oh!

Antreesy commented Jul 26, 2026

Uh oh!

nickvergessen commented Jul 26, 2026

Uh oh!

nickvergessen left a comment

Uh oh!

nickvergessen commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

nickvergessen commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

mickenordin commented Jul 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Checklist

AI (if applicable)

Manual testing:

Uh oh!

Antreesy commented Jul 26, 2026

Uh oh!

nickvergessen commented Jul 26, 2026

Uh oh!

nickvergessen left a comment

Choose a reason for hiding this comment

Uh oh!

nickvergessen commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

nickvergessen commented Jul 28, 2026

Uh oh!

mickenordin commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mickenordin commented Jul 26, 2026 •

edited

Loading