Signing request

[ArtificialOwl]

This is an attempt to add an way to confirm the origin of an incoming request when running an OCM request to ensure both party known each others

Signing Request

Signing request allows to confirm the identity of the sender.
Signing request does not encrypt nor affect its payload.
Signing request only adds metadata to the headers of the request.

Discovery

A signatory containing a keyId and the public key is added to the OCM discovery

{
  "enabled": true,
  "endPoint": "...",
  "resourceTypes": [
    [...]
  ],
  "protocols": {
    [...]
  },
  "publicKey": {
    "keyId": "https://cloud.mydomain.com/ocm#signature",
    "publicKeyPem": "[...]"
  }
}

Signature

The concept is to add unique metadata and sign them using a private/public key pair.
The location of the public key used to verify the signature will confirm the origin of the request.

Signature does not affect the data of the request, it only adds headers to it:

 {
     "(request-target)": "post /path",
     "content-length": 380,
     "date": "Mon, 08 Jul 2024 14:16:20 GMT",
     "digest": "SHA-256=U7gNVUQiixe5BRbp4Tg0xCZMTcSWXXUZI2\\/xtHM40S0=",
     "host": "hostname.of.the.recipient",
     "Signature": "keyId=\"https://author.hostname/key\",algorithm=\"ras-sha256\",headers=\"content-length date digest host\",signature=\"DzN12OCS1rsA[...]o0VmxjQooRo6HHabg==\""
 }

'content-length' is the total length of the data/content
'date' is the datetime the request have been initiated
'digest' is a checksum of the data/content
'host' is the hostname of the recipient of the request (remote when signing outgoing request, local on incoming request)
'Signature' contains the signature generated using the private key, and metadata:
    'keyId' is a unique id, formatted as an url. hostname is used to retrieve the public key via custom discovery
    'algorithm' define the algorithm used to generate signature
    'headers' contains a list of element used during the generation of the signature
    'signature' is the encrypted string, using local private key, of an array containing elements
    listed in 'headers' and their value. Some elements (content-length date digest host) are mandatory
    to ensure authenticity override protection.

[ArtificialOwl]

And an implementation of the feature on Nextcloud: nextcloud/server#45979

[glpatcern]

Hi there, interesting proposal indeed, it would nicely complement the recent additions related to discovering the remote end.

Could you please patch the spec.yaml file with the required snippet in the discovery endpoint? I'd add the publicKey section at the top level of the returned JSON though, not as one of the resourceTypes.

[ArtificialOwl]

formatted result of the edit in spec.yaml

[michielbdejong]

Great idea! Side note:
If we want to make OCM compatible with GNAP (see #98), we should require the information advertised via .well-known to match the client details described in section 2.3 of GNAP

[michielbdejong]

Also, in GNAP I just read:

A client instance that is capable of talking to multiple AS's SHOULD
use a different key for each AS to prevent a class of mix-up attacks
as described in Section 13.31 unless other mechanisms can be used to
assure the identity of the AS for a given request.

I wonder if/how that would apply to OCM.

GNAP "client instance" = OCM receiving server
GNAP "Authorization Server (AS)" = OCM sending server

[glpatcern]

Hi there, thanks for the extra contribution. I went through the proposal in more details and apart some minor fixes/rephrasing, there are a couple of questions we need to address before proceeding.

[MahdiBaghbani]

I've something to add here, it's from the ActivityPub,

Signing requests using HTTP Signatures
Server to server federation via inbox delivery POST requests is authenticated using HTTP Signatures in conjunction with the signing key from the actor's publicKey field. The keyId should link to the actor so that the publicKey field can be retrieved. At minimum, the digest field should be included in the set of headers being signed.

So the actors are the users on the server, and each user has a key pair. The requests are signed with the private key of the user initiating the request (and not the server).

There is also an Instance Actor which is the server itself.

[michielbdejong]

We should merge this into the spec as optional, great stuff!
I implemented it in OcmStub for both sending and receiving.

[glpatcern]

I concur this is a most welcome development to be merged to the spec.

I also linked #23 from a few years back as it suggests exactly the same thing.

[michielbdejong]

An RFC came out in February, looks like this is intended to replace the I-D from 2019?

[mickenordin]

This looks good to me now.

[glpatcern]

Only a few minor fixes remaining.

Otherwise, I don't think it's good to have language-specific code examples in the spec. If you want to move forward let's merge this as is, but please open an issue that the example on how to perform the signing and the verification should be done in a more abstract way, especially without language-specific primitives such as implode() (Let's say up to base64_encode(hash('sha256', utf8_encode($payload))) is fine!).

[michielbdejong]

If you want to move forward let's merge this as is

Thanks! Yes, let's merge this now and then I'll add my own ideas in a follow-up PR

[ArtificialOwl]

sorry, was overhelmed with work in the last few weeks, not even able to free me for those weekly calls