http-sig: Update http message signatures for OCM after spec review - #62543
http-sig: Update http message signatures for OCM after spec review#62543mickenordin wants to merge 2 commits into
Conversation
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>
b8eb0c3 to
97e3ba5
Compare
|
Sorry, tapped the wrong button |
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
left a comment
There was a problem hiding this comment.
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)
|
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. |
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.