[FEP-fe34] JSON-LD consumers and public keys #12

silverpill commented 2025年08月21日 02:22:47 +02:00

https://socialhub.activitypub.rocks/t/potential-security-vulnerability-remote-json-ld-contexts-may-be-used-to-bypass-restrictions-when-arbitrary-objects-are-allowed-to-be-created/5439

In that thread, 3 related problems were identified:

• Objects that don't appear as public keys may be processed as such by JSON-LD consumers. The FEP currently warns about this, but doesn't suggest a solution. This problem also arises in other situations where duck typing is used (FEP-2277).
• Is it enough for a key to be served at origin, or should it be also linked to an actor? In origin-based security model, being served at origin is enough for any object to be considered authentic. However, additional restrictions might be added (e.g. related to authorization).
• What policy should be used during signature verification: same-origin or same-owner? The FEP recommends same-origin (as the NOTE in section "Signatures" says, same-origin is simpler), but same-owner is also applicable and might be preferable if there is a requirement to check key ownership .

https://socialhub.activitypub.rocks/t/potential-security-vulnerability-remote-json-ld-contexts-may-be-used-to-bypass-restrictions-when-arbitrary-objects-are-allowed-to-be-created/5439 In that thread, 3 related problems were identified: - **Objects that don't appear as public keys may be processed as such by JSON-LD consumers**. The FEP currently warns about this, but doesn't suggest a solution. This problem also arises in other situations where duck typing is used ([FEP-2277](https://codeberg.org/silverpill/feps/src/commit/6754e99b91f862202b18725b9478b42f5665556e/2277/fep-2277.md)). - **Is it enough for a key to be served at origin, or should it be also linked to an actor?** In origin-based security model, being served at origin is enough for any object to be considered authentic. However, additional restrictions might be added (e.g. related to authorization). - **What policy should be used during signature verification: same-origin or same-owner?** The FEP recommends same-origin (as the NOTE in section "Signatures" says, same-origin is simpler), but same-owner is also applicable and might be preferable if there is a requirement to check key ownership .

silverpill commented 2025年09月06日 02:24:03 +02:00

Is it enough for a key to be served at origin, or should it be also linked to an actor?
What policy should be used during signature verification: same-origin or same-owner?

I decided to require a same-owner check and a reciprocal claim check, as a protection from insufficient validation:

In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim.

-- fediverse/fep#672

>Is it enough for a key to be served at origin, or should it be also linked to an actor? >What policy should be used during signature verification: same-origin or same-owner? I decided to require a same-owner check and a reciprocal claim check, as a protection from insufficient validation: > In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim. -- https://codeberg.org/fediverse/fep/pulls/672

silverpill commented 2025年10月12日 23:12:57 +02:00

This problem also arises in other situations where duck typing is used (FEP-2277).

This has been addressed in fediverse/fep#697.

> This problem also arises in other situations where duck typing is used (FEP-2277). This has been addressed in https://codeberg.org/fediverse/fep/pulls/697.

silverpill commented 2025年10月24日 14:25:22 +02:00

Objects that don't appear as public keys may be processed as such by JSON-LD consumers

Possible solution: don't let clients use arbitrary @context

> Objects that don't appear as public keys may be processed as such by JSON-LD consumers Possible solution: don't let clients use arbitrary `@context`