fep_fe34

Added new requirements to FEP-fe34:

https://codeberg.org/fediverse/fep/pulls/672

Previously the FEP put the burden of C2S validation solely on the originating server (producer), but I think it would be better to do corresponding security checks on the consumer side too:

- When fetching an object: verify that Content-Type includes one of the AP & AS media types.
- When verifying a signature: also perform same-owner check and verify key ownership.

Both are already considered good practices in the Fediverse.

I also attempted to clarify how fetching from origin (authentication) is related to access control (authorization).

#fep_fe34

Updating FEP-fe34: Origin-based security model:

https://codeberg.org/fediverse/fep/pulls/563/files

I described the conditions in which the model should be used: HTTP(S) identifiers and server-managed actors. Servers MUST NOT share secret keys with clients, because if keys are shared, non-admin users might impersonate other users on the same server.

This means actor registration process in FEP-ae97 is not secure, and will be replaced with a different one.

-----

The model can be used with 'ap' and DID URLs too, but FEP-fe34 currently doesn't cover this case, because it is not clear how origin should be computed for them. This is an experimental feature. I am using ("ap", <did>, 0) tuples (see FEP-ef61), but also considering introducing a new type of origin - cryptographic origin - which is not a tuple, but just a DID (WHATWG HTML standard already specifies two types: opaque origin and tuple origin; cryptographic will be the third).

#fep_fe34

I updated FEP-fe34 (origin-based security model):

https://codeberg.org/fediverse/fep/pulls/653

The "Authentication" section is fully rewritten. I moved requirements from the "Assumptions" section to sections describing related authentication methods.

Besides that, there is a major change in how embedded objects are treated. Previously, the same-origin policy was recommended. In the new version, embedded objects shouldn't be trusted except for 3 cases:

- The object of a Create activity.
- Embedded object identified by a fragment.
- Embedded anonymous object.

It is difficult for a server to guarantee authenticity of an embedded object that was published using C2S API. Such object can be embedded somewhere deep in the object graph, and verifying embedded objects at all levels is not practical.

The previous recommendation was only appropriate for a network where servers don't implement C2S API.

#fep_fe34

A minor update to FEP-fe34: Origin-based security model

https://codeberg.org/fediverse/fep/pulls/662

- Explained how to identify public keys. They can be identified by publicKeyPem and publicKeyMultibase properties ("duck typing").
- Added a warning for JSON-LD consumers. Even innocuously looking property can become publicKeyPem or publicKeyMultibase after doing JSON-LD transformations.

You can read more about this problem in this post: https://socialhub.activitypub.rocks/t/am-i-understanding-something-wrong-or-is-json-ld-remote-context-support-a-gigantic-security-vulnerability-if-any-dumb-c2s-server-implementation-tries-to-federate-with-the-current-network/5439/1

@kopper suggests possible workarounds there but I think they are way too complicated. Just don't do JSON-LD.

#fep_fe34 #jsonld #ActivityPub