4 Commits (04aa4e851efec1cf3452dfa122cee040f881aa7d)

Author	SHA1	Message	Date
Micke Nordin	dae8a36460	fix(ocm): treat RFC 9421 keyid as opaque, verify by sender origin ... 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>	2 weeks ago
Micke Nordin	410d8c144b	feat(ocm): align RFC 9421 http-sig with updated OCM spec ... 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>	2 weeks ago
Micke Nordin	1bad4fe238	fix: Make sodium optional ... This commit switches the default signature algorithm to ecdsa-p256-sha256 instead of Ed25519. This allows us to make sodium optional again, and we only pull it in to use it for verifying incomming signatures. If sodium is not installed, we throw on Ed25519 signatures instead. At least it is easy for most people to make their Nextcloud install fully RFC compliant by installing sodium. I also renamed all the Ed25519 function names to be more precis, using Jwks for the JSON Web Keys, and RFC9421 for the http-signature code, where it is needed to distinguish from draft-cavage signatures. Signed-off-by: Micke Nordin <kano@sunet.se>	3 months ago
Micke Nordin	0eb927e617	feat(http-sig): RFC 9421 protocol primitives ... Add the RFC 9421 (HTTP Message Signatures) sign/verify path alongside the existing draft-cavage implementation: - Algorithm: sodium for Ed25519, JWT::sign for RSA / ECDSA, ecdsaRawToDer for the ECDSA wire format. JWK parsing via JWK::parseKey. - SignatureBase: RFC 9421 §2.5 base construction for the derived components OCM uses plus plain HTTP fields. - ContentDigest: RFC 9530 helpers used as a covered component. - Rfc9421IncomingSignedRequest / Rfc9421OutgoingSignedRequest: request models. Parsing of Signature-Input / Signature delegates to gapple\\StructuredFields\\Parser. - IJwkResolvingSignatoryManager: capability bit signatory managers advertise to participate in RFC 9421 verification. - OcmProfile: OCM-mandated dictionary label. - SignatureManager: dispatch to RFC 9421 inbound when Signature-Input is present, outbound when rfc9421.format is set. Plus tests for each primitive and a full round-trip across the model. Signed-off-by: Micke Nordin <kano@sunet.se>	3 months ago