Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

This is because the user private key is used in HTTP Message Signature, 
when the server send messages in the outbox to receivers in message 
intended audience. Consider that this message may has been modified by 
the server, as in the case of removing bto and bcc properties, or 
"Object creation without a Create Activity" (Section 6.2.1 of Activity 
Pub specification). Summing up, the server sends a message, and this 
message is not necessarily that produced by the client. Thus, I agree  
with Emelia in general, but I think it should be more appropriate for 
the server signing the outgoing messages with its own key.

And yes, I propose to let the protocol more permissive as I can't see 
any reason to avoid clients to send messages directly.

CL

On 12/04/25 12:04, Melvin Carvalho wrote:
>
>
> so 12. 4. 2025 v 11:26 odesílatel Nils (aka Nordnick) <w3c@hhmx.de> 
> napsal:
>
>     Hi Emelia, Hi Melvin, Hi all,
>
>     i agree with Emelia here... (see below).
>
>     On 12 Apr 2025 at 10:06, emelia wrote:
>
>     [...]
>     > That is to say: you'd need to completely change how you think about
>     > doing anything with the Actor's private keys to make it
>     > user-custodial, because the private key is used for signing outgoing
>     > requests that may happen in the background & it would
>     necessarily make
>     > sense to send the users' active sessions a message going "hey,
>     can you
>     > sign this HTTP request I need to make?" for HTTP Message Signatures.
>
>     Trying to imagine, how this should work in real life, if the
>     (non-technical) user should provide a key for each signing of a HTTP
>     request in the background.
>
>     Also it would it make really hard to use multiple ways to handle an
>     account... how should a user store a key, if he or she uses multiple
>     apps and UIs on multiple devices?
>
>
> Hi Nils, great questions!
>
> I’m probably missing something obvious, but I was wondering: What’s 
> the challenge with users holding their private key on mobile?
>
> Could something like a passkey be used, so the key stays on the device 
> and is unlocked with a fingerprint?
>
> Just exploring ideas — curious what others think.
>
>
>
>     > So yes, whilst we should be encrypting private keys in databases
>     with
>     > a server-custodial key, that won't make the Actor's private key
>     useful
>     > for payments or E2EE.
>
>     There is a more or less easy way to get the control on your keys:
>     Operate an own instance. This is possible with ActivityPub, even for
>     a single user instance for personal communication.
>
>     But... what is the goal of ActivityPub, a decentralized social
>     networking protocol?
>
>     It is designed to PUBLISH activities, messages, what so ever.
>
>     It is NOT designed to provide secret one-to-one communication.
>     It is NOT designed to run financial operations.
>
>     So if you are in need of some kind of special secure communication,
>     most likely ActivityPub isn't what your are looing for...
>
>     A nice weekend to all,
>     Nils
>