Re: HTTP Signature CG report

Also, let me back up and try to address this on a slightly more abstract
level.
Server-side signing is a TEMPORARY state of affairs. Like.. it's not good,
it's just an artifact of tech limitation (lack of good client-side key
management options) at the time.
And it's definitely not the "only secure method" that the previous
discussion is implying, but exactly the opposite (something we have to put
up with currently, but will try to move away from).

If current server implementations don't handle client-side signing
correctly, that's fine, we'll have to fix that (and painfully wait till the
fixes propagate through the ecosystem).
If there's something in the AP protocol that's adding to the confusion /
making client-side signing harder, we'll fix the protocol.

(Hopefully my answers make more sense in that context.)




On Wed, Feb 7, 2024 at 11:49 AM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> > There is no way a receiving server can tell that example.com/posts/123 is
> "supposed to" be bar's ID to sign, instead of foo's.
>
> And why's that a problem? (also, let's switch to the usual Alice for legit
> post author and Mallory for the attacker).
> If Alice creates a post and client-side signs it, and then Mallory makes a
> post with the same ID and client-side signs it and sends it to another
> server -- you're right that the receiving server doesn't know who the post
> is "supposed to" belong to.
> However, that doesn't really matter. People who don't subscribe to Mallory
> won't see her posts (they'd only see Alice's posts). Is that not the case?
>
>
>
>
> On Wed, Feb 7, 2024 at 11:46 AM nightpool <eg1290@gmail.com> wrote:
>
>> I'm talking about the ID for the activity itself. The Activity is
>> attributedTo example.com/users/foo, but it purports to shares an id (
>> example.com/posts/123) with a legitimate post made by
>> example.com/users/bar. There is no way a receiving server can tell that
>> example.com/posts/123 is "supposed to" be bar's ID to sign, instead of
>> foo's.
>>
>> On Wed, Feb 7, 2024 at 11:43 AM Dmitri Zagidulin <dzagidulin@gmail.com>
>> wrote:
>>
>>> > If clients have custody of keys, then `foo@example.com` could wait
>>> for `bar@example.com` to make a post, and then sign an activity with
>>> the same ID (e.g. "example.com/posts/102930")
>>>
>>> Wait, that's not how client signing works tho. The whole point of client
>>> signing is that nobody else can sign with the same ID (cause they don't
>>> have your keys).
>>>
>>>
>>>