Require http-sig for Directory Service response

[mickenordin]

This should be a requirement IMO because a lot of trust can be derived from a federation if we trust the directory service.

[MahdiBaghbani]

I agree with this requirement. As far as I know, only Nextcloud currently supports HTTP signature verification.

Does Reva support this functionality yet?

[KrausMatthias]

I have http-sig implemented, unfortunately I decided for Ed25519 while Nextcloud apparently supports RSA only (my implementation would accept Ed25519, HMAC-Sha and ecdsa but no RSA due to timing vulnerabilities)

I think need to specify which signature types to use from https://datatracker.ietf.org/doc/html/rfc9421#hsa-registry

[KrausMatthias]

Regarding Directory Service, where would the Signing key come from? As far as I understand the Directory Service is not bound to Discovery and could be hosted e.g. in a GitHub repo?

What would http-sig add beyond Https certificates?

[MahdiBaghbani]

That's a valid point, @KrausMatthias. I believe the directory service host should also provide an OCM discovery endpoint at /.well-known/ocm for publishing its public key.

could be hosted e.g. in a GitHub repo?

That's a good point. The advantage of Signed HTTP requests was primarily to verify the authenticity of POST requests. However, since the discovery endpoint uses only GET requests, we can rely on the TLS certificate matching the domain to ensure authenticity, correct?

[mickenordin]

I think it ought to be a configuration matter, that you configure the signing key along with the url to the discovery service

[glpatcern]

To answer Mahdi, Reva does not implement any http-sig yet (and PRs are welcome of course ;-) ).

But I resonate with Matthias that it seems a bit of an overkill to require http-sig from a system that only offers static content, that could be served from any repository (including some EFSSs!)

[mickenordin]

Hiw about adding a signature to the payload it self?

...
  "Signature": {
    "algo": ...,
    "signature": ...
  },
...

The upside, if we can make sure the payload is from the trusted source, is that we can trust the servers in the federation too.

[glpatcern]

Hiw about adding a signature to the payload it self?

But how would you validate the signature? What would you require from the remote server?

[mickenordin]

Hiw about adding a signature to the payload it self?

But how would you validate the signature? What would you require from the remote server?

To configure a discover service in your efss, you would add a url and a public key to your configuration, you would then use that public key to validate the signature.

[KrausMatthias]

Hiw about adding a signature to the payload it self?

...
  "Signature": {
    "algo": ...,
    "signature": ...
  },
...

The upside, if we can make sure the payload is from the trusted source, is that we can trust the servers in the federation too.

I don't think it would work like that as then the signature would become part of the payload.

[ocm-mail-bot]

You would have to exclude the signature from the message when you validate it, similar to when you calculate the checksum for a package. Den 31 oktober 2025 09:24:59 CET, KrausMatthias ***@***.***> skrev:

…

KrausMatthias left a comment (cs3org/OCM-API#290) > Hiw about adding a signature to the payload it self? > > ``` > ... > "Signature": { > "algo": ..., > "signature": ... > }, > ... > ``` > > The upside, if we can make sure the payload is from the trusted source, is that we can trust the servers in the federation too. I don't think it would work like that as then the signature would become part of the payload. -- Reply to this email directly or view it on GitHub: #290 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[glpatcern]

I think I'm missing something here. The Directory Service's list is to be consumed by many OCM Servers, and a signature would have to be checked against some public key offered by the Directory Service itself. IMHO that is what is too heavy in terms of requirement for such a service: after all, when configuring an OCM Server, their administrators still have to trust the administrators of the Directory Service that they don't tamper with the list or that the server is not compromised, and http-sig does not bring much extra value for this anyway.

Also, as discussed over the chat: an OCM Server that queries a remote Discovery endpoint (either based on user input or from a Directory list) should anyway take all measures to protect against XSS-like attacks, as those endpoints are unauthenticated and I could let an OCM Server download some malicious discovery paylaod. We'll have to expand on this in the Security Considerations of the I-D.

[mickenordin]

Ok, so let me describe the flow I am imagining:

1. As an operator of a discovery service, I generate a json file with the list of servers in the federation, I sign the payload somehow (maybe jws: https://datatracker.ietf.org/doc/rfc7515/) and then I can serve the file from any where. The private key it self can even be stored off line, or in an HSM, for enhanced security.

2. As a consumer of a discovery service, I configure my EFSS with the url to the file, and the public key of the discovery service.

3. I validate the contents of the file, and use the signature as a way to transfer trust from the discovery service to the servers in the list, i.e. I can use the fact that the list is signed to trust that the servers on the list are themselfs trust worthy.

If there is no such mechanism, adding or replacing servers in the list can be trivialy done if the web servers serving the list is compromized, but if the list is signed, I would not need to trust the web server or network of the discovery service, only that they can manage the private key in a secure way.

[glpatcern]

Thanks, much clearer now.

Now, the requirement on the Directory Service is to host the list with the signature and to offer the public key somewhere, for OCM Servers to consume it and validate the list's content. If the signature could be incorporated in the list (and JWS seems a reasonable choice), where would the public key be offered? Would it make sense to have it also as part of the list (possibly JWS and JWE have provisions for that)?

My point is not to impose that a Directory Service be a kind of OCM Server with a /.well-known/ocm endpoint just to expose the pub key.

[mickenordin]

My point is not to impose that a Directory Service be a kind of OCM Server with a /.well-known/ocm endpoint just to expose the pub key.

I agree with this, and I am thinking that the public key is distributed out of band, along with the url to the discovery service. So the idea is that we should receive the key form a trusted source separated from the discovery service itself.