Re: HTTP Signature CG report

> 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).
>>
>>
>>