[feat] Support JSON-LD signatures - Implied Akkoma is misbehaving #471

Closed
opened 2023-02-18 06:58:27 +00:00 by gamerfort · 8 comments

The idea

I was looking to set up a possible relay and found the following recent change in the documentation for Asonix relay software:

9b809913ad

	### Known issues
Pleroma and Akkoma do not support validating JSON-LD signatures, meaning many activities such as Delete, Update, Add, and Remove will be rejected with a message similar to `WARN: Response from https://example.com/inbox, "Invalid HTTP Signature"`. This is normal and not an issue with the relay.

I don't know quite what that means, but I suspect it isn't the HTTP signature, but a separate JSON-LD signature.

This request would be to add validation of JSON-LD signatures.

The reasoning

I'm not quite sure of the scope of the comment in the Asonix relay documentation, but it seems to imply that Akkoma instances are "misbehaving?" when it comes to many core Activities?

Since I don't really understand all the technical details, I don't know how "serious" the situation is, but it certainly seems to imply that Akkoma instances won't honor Delete, Update, Add, and Remove activities from subscribed instances.

Have you searched for this feature request?

  • I have double-checked and have not found this feature request mentioned anywhere.
  • This feature is related to the Akkoma backend specifically, and not pleroma-fe.
### The idea I was looking to set up a possible relay and found the following recent change in the documentation for Asonix relay software: https://git.asonix.dog/asonix/relay/commit/9b809913ad05a2ba773956bed6bee34d68ba3838 ``` ### Known issues Pleroma and Akkoma do not support validating JSON-LD signatures, meaning many activities such as Delete, Update, Add, and Remove will be rejected with a message similar to `WARN: Response from https://example.com/inbox, "Invalid HTTP Signature"`. This is normal and not an issue with the relay. ``` I don't know quite what that means, but I suspect it isn't the HTTP signature, but a separate JSON-LD signature. This request would be to add validation of JSON-LD signatures. ### The reasoning I'm not quite sure of the scope of the comment in the Asonix relay documentation, but it seems to imply that Akkoma instances are "misbehaving?" when it comes to many core Activities? Since I don't really understand all the technical details, I don't know how "serious" the situation is, but it certainly seems to imply that Akkoma instances won't honor Delete, Update, Add, and Remove activities from subscribed instances. ### Have you searched for this feature request? - [x] I have double-checked and have not found this feature request mentioned anywhere. - [x] This feature is related to the Akkoma backend specifically, and not pleroma-fe.
gamerfort added the
feature request
label 2023-02-18 06:58:27 +00:00
gamerfort changed title from [feat] Support JSON-LD signatures to [feat] Support JSON-LD signatures - Implied Akkoma is misbehaving 2023-02-18 07:00:14 +00:00
Contributor

Adding context: from what I understand, ActivityPub as a specification does not actually say how to sign posts, so there's two approaches adopted by implementations: JSON-LD and HTTP Signatures. The thing with JSON-LD signatures is that they are embedded in post bodies and so, can be relayed towards other citizens of the web that also support JSON-LD relatively easily, HTTP signatures only apply to a single request/response, and so, are detached from the request/response body, so the approach to relay them is different.

Mastodon already generates HTTP Signatures, it's why none of this has caught fire over the years, the issue is more about relays that emit JSON-LD specifically rather than Akkoma won't support posts from other instances, as most implementations generate HTTP sigs.

I don't know the context of why Pleroma has not added support JSON-LD, maybe code complexity? Any Pleroma archeologists around here to help on that one?

Adding context: from what I understand, ActivityPub as a specification does not actually say how to sign posts, so there's two approaches adopted by implementations: JSON-LD and HTTP Signatures. The thing with JSON-LD signatures is that they are embedded in post bodies and so, can be relayed towards other citizens of the web that also support JSON-LD relatively easily, HTTP signatures only apply to a single request/response, and so, are detached from the request/response body, so the approach to relay them is different. Mastodon already generates HTTP Signatures, it's why none of this has caught fire over the years, the issue is more about relays that emit JSON-LD *specifically* rather than Akkoma won't support posts from other instances, as most implementations generate HTTP sigs. I don't know the context of why Pleroma has not added support JSON-LD, maybe code complexity? Any Pleroma archeologists around here to help on that one?
Author

Thank you for the added context. I wonder now if there is wide support for JSON-LD signatures. The rest of that change commit seems to say that it's pretty common. Either way I also wonder why it wasn't added. I wonder also since Mastodon apparently only processes JSON-LD as simple JSON instead of JSON-LD.

Thank you for the added context. I wonder now if there is wide support for JSON-LD signatures. The rest of that change commit seems to say that it's pretty common. Either way I also wonder why it wasn't added. I wonder also since Mastodon apparently only processes JSON-LD as simple JSON instead of JSON-LD.
Author

https://docs.joinmastodon.org/spec/security/

Looks like Mastodon does use them some, but specifically recommends against implementing them due to being superceeded.

https://docs.joinmastodon.org/spec/security/ Looks like Mastodon does use them some, but specifically recommends against implementing them due to being superceeded.

JSON-LD is not supported because it is notably different to the raw data and the pattern matching would completely break

JSON-LD is not supported because it is notably different to the raw data and the pattern matching would completely break
Author

JSON-LD is not supported because it is notably different to the raw data and the pattern matching would completely break

Would this apply to just signature verification as well? I don't know enough and just trying to understand.

> JSON-LD is not supported because it is notably different to the raw data and the pattern matching would completely break Would this apply to just signature verification as well? I don't know enough and just trying to understand.

well yes, we can't pattern match the signature if we don't ld-decode the entire document

well yes, we can't pattern match the signature if we don't ld-decode the entire document
Author

well yes, we can't pattern match the signature if we don't ld-decode the entire document

I thought Mastodon doesn't actually process as JSON-LD either and just parses as simple JSON.

https://mastodon.online/@Gargron@mastodon.social/109837277162493708

And the Mastodon documents list how they take the JSON key pairs and validate the signature.

"signature": {
    "type": "RsaSignature2017",
    "creator": "https://mastodon.example/users/username#main-key",
    "created": "2019-12-08T03:48:33.901Z",
    "signatureValue": "s69F3mfddd99dGjmvjdjjs81e12jn121Gkm1"
}
Verifying LD signatures

To verify a signature, Mastodon uses the following algorithm:

Make sure that a signature exists and is a hash.
Make sure that signature[type] is RsaSignature2017.
Fetch the signature[creator] URI. Make sure the creator exists.
Strip type, id, and signatureValue from the signature, leaving only signature[creator] and signature[created].
Base64-decode the signatureValue and verify it against the public key in signature[creator].

> well yes, we can't pattern match the signature if we don't ld-decode the entire document I thought Mastodon doesn't actually process as JSON-LD either and just parses as simple JSON. https://mastodon.online/@Gargron@mastodon.social/109837277162493708 And the Mastodon documents list how they take the JSON key pairs and validate the signature. ``` "signature": { "type": "RsaSignature2017", "creator": "https://mastodon.example/users/username#main-key", "created": "2019-12-08T03:48:33.901Z", "signatureValue": "s69F3mfddd99dGjmvjdjjs81e12jn121Gkm1" } Verifying LD signatures To verify a signature, Mastodon uses the following algorithm: Make sure that a signature exists and is a hash. Make sure that signature[type] is RsaSignature2017. Fetch the signature[creator] URI. Make sure the creator exists. Strip type, id, and signatureValue from the signature, leaving only signature[creator] and signature[created]. Base64-decode the signatureValue and verify it against the public key in signature[creator]. ```

it appears that ld signatures are long deprecated and some new standard is proposed

it appears that ld signatures are long deprecated and some new standard is proposed
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#471
No description provided.